pkt-line: allow writing of LARGE_PACKET_MAX buffers
When we send out pkt-lines with refnames, we use a static
1000-byte buffer. This means that the maximum size of a ref
over the git protocol is around 950 bytes (the exact size
depends on the protocol line being written, but figure on a sha1
plus some boilerplate).
This is enough for any sane workflow, but occasionally odd
things happen (e.g., a bug may create a ref "foo/foo/foo/..."
accidentally). With the current code, you cannot even use
"push" to delete such a ref from a remote.
Let's switch to using a strbuf, with a hard-limit of
LARGE_PACKET_MAX (which is specified by the protocol). This
matches the size of the readers, as of 74543a0 (pkt-line:
provide a LARGE_PACKET_MAX static buffer, 2013-02-20).
Versions of git older than that will complain about our
large packets, but it's really no worse than the current
behavior. Right now the sender barfs with "impossibly long
line" trying to send the packet, and afterwards the reader
will barf with "protocol error: bad line length %d", which
is arguably better anyway.
Note that we're not really _solving_ the problem here, but
just bumping the limits. In theory, the length of a ref is
unbounded, and pkt-line can only represent sizes up to
65531 bytes. So we are just bumping the limit, not removing
it. But hopefully 64K should be enough for anyone.
As a bonus, by using a strbuf for the formatting we can
eliminate an unnecessary copy in format_buf_write.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
A request to store an empty note via "git notes" meant to remove
note from the object but with --allow-empty we will store a (surprise!)
note that is empty. In the longer run, we might want to deprecate
the somewhat unintuitive "emptying means deletion" behaviour.
* jh/empty-notes:
t3301: modernize style
notes: empty notes should be shown by 'git log'
builtin/notes: add --allow-empty, to allow storing empty notes
builtin/notes: split create_note() to clarify add vs. remove logic
builtin/notes: simplify early exit code in add()
builtin/notes: refactor note file path into struct note_data
builtin/notes: improve naming
t3301: verify that 'git notes' removes empty notes by default
builtin/notes: fix premature failure when trying to add the empty blob
"git checkout $treeish $path", when $path in the index and the
working tree already matched what is in $treeish at the $path,
still overwrote the $path unnecessarily.
* jk/checkout-from-tree:
checkout $tree: do not throw away unchanged index entries
Allow passing extra set of arguments when ssh is invoked to create
an encrypted & authenticated connection by introducing a new environment
variable GIT_SSH_COMMAND, whose contents is interpreted by shells.
This is not possible with existing GIT_SSH mechanism whose
invocation bypasses shells, which was designed more to match what
other programs with similar variables did, not necessarily to be
more useful.
* tq/git-ssh-command:
git_connect: set ssh shell command in GIT_SSH_COMMAND
Ralf reported that '--recurse-submodules' option in push.c should not be
translated [1]. Before his commit is merged, remove superfluous
translations for push.c.
In order to catch up with the release of Git 2.2.0 final, make a batch
l10n update for the new l10n change brought by commit d52adf1 (trailer:
display a trailer without its trailing newline).
gitweb: hack around CGI's list-context param() handling
As of CGI.pm's 4.08 release, the behavior to call
CGI::param() in a list context is deprecated (because it can
be potentially unsafe if called inside a hash constructor).
This causes gitweb to issue a warning for some of our code,
which in turn causes the tests to fail.
Our use is in fact _not_ one of the dangerous cases, as we
are intentionally using a list context. The recommended
route by 4.08 is to use the new CGI::multi_param() call to
make it explicit that we know what we are doing.
However, that function is only available in 4.08, which is
about a month old; we cannot rely on having it.
One option would be to set $CGI::LIST_CONTEXT_WARN globally,
which turns off the warning. However, that would eliminate
the protection these newer releases are trying to provide.
We want to annotate each site as OK using the new function.
So instead, let's check whether CGI provides the
multi_param() function, and if not, provide an
implementation that just wraps param(). That will work on
both old and new versions of CGI. Sadly, we cannot just
check defined(\&CGI::multi_param), because CGI uses the
autoload feature, which claims that all functions are
defined. Instead, we just do a version check.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
create_default_files(): don't set u+x bit on $GIT_DIR/config
Since time immemorial, the test of whether to set "core.filemode"
has been done by trying to toggle the u+x bit on $GIT_DIR/config,
which we know always exists, and then testing whether the change
"took". I find it somewhat odd to use the config file for this
test, but whatever.
The test code didn't set the u+x bit back to its original state
itself, instead relying on the subsequent call to git_config_set()
to re-write the config file with correct permissions.
But ever since
daa22c6f8d config: preserve config file permissions on edits (2014-05-06)
git_config_set() copies the permissions from the old config file to
the new one. This is a good change in and of itself, but it
invalidates the create_default_files()'s assumption, causing "git
init" to leave the executable bit set on $GIT_DIR/config.
Reset the permissions on $GIT_DIR/config when we are done with the
test in create_default_files().
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'master' of git://github.com/git-l10n/git-po
* 'master' of git://github.com/git-l10n/git-po:
l10n: de.po: translate 62 new messages
l10n: de.po: Fixup one translation
l10n: de.po: use imperative form for command options
Windows: correct detection of EISDIR in mingw_open()
According to the Linux open(2) man page, open() must return EISDIR
if a directory was attempted to be opened for writing. Our emulation
in mingw_open() does not get this right: it checks only for O_CREAT.
Fix it to check for a write request.
This fixes a failure in reflog handling, which opens files with
O_APPEND|O_WRONLY, but without O_CREAT, and expects EISDIR when the
named file happens to be a directory.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make this test script appear somewhat less old-fashioned:
- Use test helper functions:
- write_script
- test_commit
- test_write_lines
- test_line_count
- test_config
- test_unconfig
- test_path_is_missing
- Remove whitespace between redirection operators and their targets.
- Move preparation of "expect" files into tests.
- Rename "output" files to "actual".
- More consistent quoting, especially around commands that might
expand to nothing.
- More visibility of important whitespace with ${indent}.
- Combine pairs of tests that unnecessarily split setup and verification.
Improved-by: Eric Sunshine <sunshine@sunshineco.com> Improved-by: Junio C Hamano <gitster@pobox.com> Improved-by: Michael Blume <blume.mike@gmail.com> Improved-by: Jeff King <peff@peff.net> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
checkout $tree: do not throw away unchanged index entries
When we "git checkout $tree", we pull paths from $tree into
the index, and then check the resulting entries out to the
worktree. Our method for the first step is rather
heavy-handed, though; it clobbers the entire existing index
entry, even if the content is the same. This means we lose
our stat information, leading checkout_entry to later
rewrite the entire file with identical content.
Instead, let's see if we have the identical entry already in
the index, in which case we leave it in place. That lets
checkout_entry do the right thing. Our tests cover two
interesting cases:
1. We make sure that a file which has no changes is not
rewritten.
2. We make sure that we do update a file that is unchanged
in the index (versus $tree), but has working tree
changes. We keep the old index entry, and
checkout_entry is able to realize that our stat
information is out of date.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test misused a URL "file://." to mean "relative to here",
which we no longer accept.
In a file:// URL, typically there is no host, and RFC1738 says that
file:///<path> should be used.
Update t5705 to use a working URL.
Reported-by: Michael Blume <blume.mike@gmail.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/notes: add --allow-empty, to allow storing empty notes
Although the "git notes" man page advertises that we support binary-safe
notes addition (using the -C option), we currently do not support adding
the empty note (i.e. using the empty blob to annotate an object). Instead,
an empty note is always treated as an intent to remove the note
altogether.
Introduce the --allow-empty option to the add/append/edit subcommands,
to explicitly allow an empty note to be stored into the notes tree.
Also update the documentation, and add test cases for the new option.
Reported-by: James H. Fisher <jhf@trifork.com> Improved-by: Kyle J. McKay <mackyle@gmail.com> Improved-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/notes: split create_note() to clarify add vs. remove logic
create_note() has a non-trivial interface, and comprises three loosely
related parts:
1. launching the editor with the note contents, if needed
2. appending to an existing note, if append_only was given
3. adding or removing the resulting note, based on whether it's non-empty
Split it along those lines to make the logic clearer: The first part
goes into a new function - prepare_note_data(), with a simpler interface.
The second part is moved into append_edit(), which is the only user of
this code. Finally, the add vs. remove decision is moved into the callers
(add() and append_edit()), keeping the logic for writing the actual note
object in a separate function: write_note_data().
Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, git-fast-import and -export link to each
other, and gitremote-helpers links to existing remote
helpers, and vice versa. Also link to fast-import from the
remote helper spec, as this is relevant for remote helpers
using the fast-import format.
Signed-off-by: Max Horn <max@quendi.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
run-command: use void to declare that functions take no parameters
Explicitly declare that git_atexit_dispatch() and git_atexit_clear()
take no parameters instead of leaving their parameter list empty and
thus unspecified.
Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In preparation for some needed refactoring, rename struct msg_arg to
struct note_data, and rename its instances from "msg" to "d" (also
removing some unnecessary parentheses). The 'msg_arg' name was
inherited from tag.c, but is not really a good name for the contents
of a note.
Also rename write_note_data() to copy_obj_to_fd(), which more aptly
describes what it actually does: Copying the contents of a git object
(given by its SHA1) into a given file descriptor.
Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t3301: verify that 'git notes' removes empty notes by default
Add test cases documenting the current behavior when trying to
add/append/edit empty notes. This is in preparation for adding
--allow-empty; to allow empty notes to be stored.
Improved-by: Eric Sunshine <sunshine@sunshineco.com> Improved-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/notes: fix premature failure when trying to add the empty blob
This fixes a small buglet when trying to explicitly add the empty blob
as a note object using the -c or -C option to git notes add/append.
Instead of failing with a nonsensical error message indicating that the
empty blob does not exist, we should rather behave as if an empty notes
message was given (e.g. using -m "" or -F /dev/null).
The next patch contains a test that verifies the fixed behavior.
Found-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Convert users of struct child_process to using the managed argv_array
args instead of providing their own. This shortens the code a bit and
ensures that the allocated memory is released automatically after use.
Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
trailer: use CHILD_PROCESS_INIT in apply_command()
Initialize the struct child_process variable cp at declaration time.
This is shorter, saves a function call and prevents using the variable
before initialization by mistake.
Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
trailer: display a trailer without its trailing newline
Trailers passed to the parse_trailer() function often have
a trailing newline. When erroring out, we should display
the invalid trailer properly, that means without any
trailing newline.
Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t1410: fix breakage on case-insensitive filesystems
Two tests recently added to t1410 create branches "a" and
"a/b" to test d/f conflicts on reflogs. Earlier, unrelated
tests in that script create the path "A/B" in the working
tree. There's no conflict on a case-sensitive filesystem,
but on a case-insensitive one, "git log" will complain that
"a/b" is both a revision and a working tree path.
We could fix this by using a "--" to disambiguate, but we
are probably better off using names that are less confusing
to make it more clear that they are unrelated to the working
tree files. This patch turns "a/b" into "one/two".
Reported-by: Michael Blume <blume.mike@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git_connect: set ssh shell command in GIT_SSH_COMMAND
It may be impractical to install a wrapper script for GIT_SSH
when additional parameters need to be passed. Provide an alternative
way of specifying a shell command to be run, including command line
arguments, by means of the GIT_SSH_COMMAND environment variable,
which behaves like GIT_SSH but is passed to the shell.
The special circuitry to modify parameters in the case of using
PuTTY's plink/tortoiseplink is activated only when using GIT_SSH;
in the case of using GIT_SSH_COMMAND, it is deliberately left up to
the user to make any required parameters adaptation before calling
the underlying ssh implementation.
Signed-off-by: Thomas Quinot <thomas@quinot.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rs/use-child-process-init-more:
bundle: split out ref writing from bundle_create
bundle: split out a helper function to compute and write prerequisites
bundle: split out a helper function to create pack data
use child_process_init() to initialize struct child_process variables
The option name "--store" was used early in development, but
never even made it into an applied patch, let alone a
released version of git. I forgot to update the matching
documentation at the time, though.
Noticed-by: Jesse Hopkins <jesse.hopkins@lmco.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
While using diff-highlight with other tools, I have discovered that Python
ignores SIGPIPE by default. Unfortunately, this also means that tools
attempting to launch a pager under Python--and don't realize this is
happening--means that the subprocess inherits this setting. In this case, it
means diff-highlight will be launched with SIGPIPE being ignored. Let's work
with those broken scripts by restoring the default SIGPIPE handler.
Signed-off-by: John Szakmeister <john@szakmeister.net> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
ignore stale directories when checking reflog existence
When we update a ref, we have two rules for whether or not
we actually update the reflog:
1. If the reflog already exists, we will always append to
it.
2. If log_all_ref_updates is set, we will create a new
reflog file if necessary.
We do the existence check by trying to open the reflog file,
either with or without O_CREAT (depending on log_all_ref_updates).
If it fails, then we check errno to see what happened.
If we were not using O_CREAT and we got ENOENT, the file
doesn't exist, and we return success (there isn't a reflog
already, and we were not told to make a new one).
If we get EISDIR, then there is likely a stale directory
that needs to be removed (e.g., there used to be "foo/bar",
it was deleted, and the directory "foo" was left. Now we
want to create the ref "foo"). If O_CREAT is set, then we
catch this case, try to remove the directory, and retry our
open. So far so good.
But if we get EISDIR and O_CREAT is not set, then we treat
this as any other error, which is not right. Like ENOENT,
EISDIR is an indication that we do not have a reflog, and we
should silently return success (we were not told to create
it). Instead, the current code reports this as an error, and
we fail to update the ref at all.
Note that this is relatively unlikely to happen, as you
would have to have had reflogs turned on, and then later
turned them off (it could also happen due to a bug in fetch,
but that was fixed in the previous commit). However, it's
quite easy to fix: we just need to treat EISDIR like ENOENT
for the non-O_CREAT case, and silently return (note that
this early return means we can also simplify the O_CREAT
case).
Our new tests cover both cases (O_CREAT and non-O_CREAT).
The first one already worked, of course.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we start the git-fetch program, we call git_config to
load all config, but our callback only processes the
fetch.prune option; we do not chain to git_default_config at
all.
This means that we may not load some core configuration
which will have an effect. For instance, we do not load
core.logAllRefUpdates, which impacts whether or not we
create reflogs in a bare repository.
Note that I said "may" above. It gets even more exciting. If
we have to transfer actual objects as part of the fetch,
then we call fetch_pack as part of the same process. That
function loads its own config, which does chain to
git_default_config, impacting global variables which are
used by the rest of fetch. But if the fetch is a pure ref
update (e.g., a new ref which is a copy of an old one), we
skip fetch_pack entirely. So we get inconsistent results
depending on whether or not we have actual objects to
transfer or not!
Let's just load the core config at the start of fetch, so we
know we have it (we may also load it again as part of
fetch_pack, but that's OK; it's designed to be idempotent).
Our tests check both cases (with and without a pack). We
also check similar behavior for push for good measure, but
it already works as expected.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>