When using rebase --interactive where one of the lines is marked as
'edit' this is the resulting output:
Stopped at ec3b9c4... stuffYou can amend the commit now, with
git commit --amend
Once you are satisfied with your changes, run
git rebase --continue
A newline character is missing at the end of the "Stopped at ..." line and
before the "You can amend ..." line. This patch fixes the malformed output by
adding the missing newline character to the end of the "Stopped at ..." line.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document memihash_cont() and hashmap_disallow_rehash()
in Documentation/technical/api-hashmap.txt.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach remote-curl to understand push options and to be able to convey
them across HTTP.
Signed-off-by: Brandon Williams <bmwill@google.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git send-pack --stateless-rpc" puts each request in a sequence of pkt-lines
followed by a flush-pkt. The push option code forgot about this and sends push
options and their terminating delimiter as ordinary pkt-lines that get their
length header stripped off by remote-curl before being sent to the server.
The result is multiple malformed requests, which the server rejects.
Fortunately send-pack --stateless-rpc already is aware of this "pkt-line within
pkt-line" framing for the update commands that precede push options. Handle
push options the same way.
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Brandon Williams <bmwill@google.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are three issues with the test:
* The syntax of the here-doc was wrong, such that the entire test was
sucked into the here-doc, which is why the test succeeded.
* The variable $submodulesha1 was not expanded as it was inside a quoted
here text. We do not want to quote EOF marker for this.
* The redirection from the git command to the output file for comparison
was wrong as the -C operator from git doesn't apply to the redirect path.
Also we're interested in stderr of that command.
Noticed-by: Jan Palus <jan.palus@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently when there are untracked changes in a file "one" and in a file
"two" in the repository and the user uses:
git stash push -k one
all changes in "two" are wiped out completely. That is clearly not the
intended result. Make sure that only the files given in the pathspec
are changed when git stash push -k <pathspec> is used.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For "git stash -p --no-keep-index", the pathspec argument is currently
not passed to "git reset". This means that changes that are staged but
that are excluded from the pathspec still get unstaged by git stash -p.
Make sure that doesn't happen by passing the pathspec argument to the
git reset in question, bringing the behaviour in line with "git stash --
<pathspec>".
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git stash push uses other git commands internally. Currently it only
passes the -q flag to those if the -q flag is passed to git stash. when
using 'git stash push -p -q --no-keep-index', it doesn't even pass the
flag on to the internal reset at all.
It really is enough for the user to know that the stash is created,
without bothering them with the internal details of what's happening.
Always pass the -q flag to the internal git clean and git reset
commands, to avoid unnecessary and potentially confusing output.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach hashmap to allow rehashes to be suppressed.
This is useful when hashmaps are accessed by multiple
threads. It still requires the caller to properly
manage their locking. This just prevents unexpected
rehashing during inserts and deletes.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add variant of memihash() to allow the hash computation to
be continued. There are times when we compute the hash on
a full path and then the hash on just the path to the parent
directory. This can be expensive on large repositories.
With this, we can hash the parent directory first. And then
continue the computation to include the "/filename".
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Specify an initial size for the istate.dir_hash HashMap matching
the size of the istate.name_hash.
Previously hashmap_init() was given 0, causing a 64 bucket
hashmap to be created. When working with very large
repositories, this would cause numerous rehash() calls to
realloc and rebalance the hashmap. This is especially true
when the worktree is deep, with many directories containing
a few files.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This came as part of jk/quote-env-path-list-component and was merged
to 2.11.1 and later.
Noticed-by: Jan Palus <jan.palus@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-describe tells you the version number you're at, or errors out, e.g.
when you run it outside of a repository, which may happen when downloading
a tar ball instead of using git to obtain the source code.
To keep this property of only erroring out, when not in a repository,
severe (submodule) errors must be downgraded to reporting them gently
instead of having git-describe error out completely.
To achieve that a flag '--broken' is introduced, which is in the same
vein as '--dirty' but uses an actual child process to check for dirtiness.
When that child dies unexpectedly, we'll append '-broken' instead of
'-dirty'.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was an oversight in 55856a35b2 (rm: absorb a submodules git dir
before deletion, 2016-12-27), as the body of the test changed without
adapting the test subject.
Signed-off-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent update to "rebase -i" started showing a message that is not
a warning with "warning:" prefix by mistake. This has been fixed.
* js/rebase-helper:
sequencer: drop "warning:" when stopping for edit
The configuration file learned a new "includeIf.<condition>.path"
that includes the contents of the given path only when the
condition holds. This allows you to say "include this work-related
bit only in the repositories under my ~/work/ directory".
* nd/conditional-config-include:
config: add conditional include
config.txt: reflow the second include.path paragraph
config.txt: clarify multiple key values in include.path
Code clean-up.
* jk/pack-name-cleanups:
index-pack: make pointer-alias fallbacks safer
replace snprintf with odb_pack_name()
odb_pack_keep(): stop generating keepfile name
sha1_file.c: make pack-name helper globally accessible
move odb_* declarations out of git-compat-util.h
Code to read submodule.<name>.ignore config did not state the
variable name correctly when giving an error message diagnosing
misconfiguration.
* sb/submodule-config-parse-ignore-fix:
submodule-config: correct error reporting for invalid ignore value
The command line prompt (in contrib/) learned a new 'tag' style
that can be specified with GIT_PS1_DESCRIBE_STYLE, to describe a
detached HEAD with "git describe --tags".
* mg/prompt-describe-tags:
git-prompt: add a describe style for any tags
"Cc:" on the trailer part does not have to conform to RFC strictly,
unlike in the e-mail header. "git send-email" has been updated to
ignore anything after '>' when picking addresses, to allow non-address
cruft like " # stable 4.4" after the address.
* jh/send-email-one-cc:
send-email: only allow one address per body tag
The code that parses header fields in the commit object has been
updated for (micro)performance and code hygiene.
* rs/commit-parsing-optim:
commit: don't check for space twice when looking for header
commit: be more precise when searching for headers
"git show-branch" expected there were only very short branch names
in the repository and used a fixed-length buffer to hold them
without checking for overflow.
* jk/show-branch-lift-name-len-limit:
show-branch: use skip_prefix to drop magic numbers
show-branch: store resolved head in heap buffer
show-branch: drop head_len variable
A caller of tempfile API that uses stdio interface to write to
files may ignore errors while writing, which is detected when
tempfile is closed (with a call to ferror()). By that time, the
original errno that may have told us what went wrong is likely to
be long gone and was overwritten by an irrelevant value.
close_tempfile() now resets errno to EIO to make errno at least
predictable.
* jk/tempfile-ferror-fclose-confusion:
tempfile: set errno to a known value before calling ferror()
"git remote rm X", when a branch has remote X configured as the
value of its branch.*.remote, tried to remove branch.*.remote and
branch.*.merge and failed if either is unset.
* rl/remote-allow-missing-branch-name-merge:
remote: ignore failure to remove missing branch.<name>.merge
A "gc.log" file left by a backgrounded "gc --auto" disables further
automatic gc; it has been taught to run at least once a day (by
default) by ignoring a stale "gc.log" file that is too old.
* dt/gc-ignore-old-gc-logs:
gc: ignore old gc.log files
"git upload-pack", which is a counter-part of "git fetch", did not
report a request for a ref that was not advertised as invalid.
This is generally not a problem (because "git fetch" will stop
before making such a request), but is the right thing to do.
* jt/upload-pack-error-report:
upload-pack: report "not our ref" to client
A leak in a codepath to read from a packed object in (rare) cases
has been plugged.
* rs/sha1-file-plug-fallback-base-leak:
sha1_file: release fallback base's memory in unpack_entry()
There is no need for Python only to give a few messages to the
standard error stream, but we somehow did.
* ss/remote-bzr-hg-placeholder-wo-python:
contrib: git-remote-{bzr,hg} placeholders don't need Python
"git diff --quiet" relies on the size field in diff_filespec to be
correctly populated, but diff_populate_filespec() helper function
made an incorrect short-cut when asked only to populate the size
field for paths that need to go through convert_to_git() (e.g. CRLF
conversion).
* jc/diff-populate-filespec-size-only-fix:
diff: do not short-cut CHECK_SIZE_ONLY check in diff_populate_filespec()
"Dumb http" transport used to misparse a nonsense http-alternates
response, which has been fixed.
* jk/http-walker-buffer-underflow-fix:
http-walker: fix buffer underflow processing remote alternates
"git status --porcelain" is supposed to give a stable output, but a
few strings were left as translatable by mistake.
* mg/status-porcelain-no-i18n:
git-status: make porcelain more robust
We may take the path to a bundle file as an argument, and
need to adjust the filename based on the prefix we
discovered while setting up the git directory. We do so
manually into a fixed-size buffer, but using
prefix_filename() is the normal way.
Besides being more concise, there are two subtle
improvements:
1. The original inserted a "/" between the two paths, even
though the "prefix" argument always has the "/"
appended. That means that:
cd subdir && git bundle verify ../foo.bundle
was looking at (and reporting) subdir//../foo.bundle.
Harmless, but ugly. Using prefix_filename() gets this
right.
2. The original checked for an absolute path by looking
for a leading '/'. It should have been using
is_absolute_path(), which also covers more cases on
Windows (backslashes and dos drive prefixes).
But it's easier still to just pass the name to
prefix_filename(), which handles this case
automatically.
Note that we'll just leak the resulting buffer in the name
of simplicity, since it needs to last through the duration
of the program anyway.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The prefix_filename function used to do an early return when
there was no prefix on non-Windows platforms, but always
allocated on Windows so that it could call convert_slashes().
Now that the function always allocates, we can unify the
logic and make convert_slashes() the only conditional part.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The prefix_filename() function returns a pointer to static
storage, which makes it easy to use dangerously. We already
fixed one buggy caller in hash-object recently, and the
calls in apply.c are suspicious (I didn't dig in enough to
confirm that there is a bug, but we call the function once
in apply_all_patches() and then again indirectly from
parse_chunk()).
Let's make it harder to get wrong by allocating the return
value. For simplicity, we'll do this even when the prefix is
empty (and we could just return the original file pointer).
That will cause us to allocate sometimes when we wouldn't
otherwise need to, but this function isn't called in
performance critical code-paths (and it already _might_
allocate on any given call, so a caller that cares about
performance is questionable anyway).
The downside is that the callers need to remember to free()
the result to avoid leaking. Most of them already used
xstrdup() on the result, so we know they are OK. The
remainder have been converted to use free() as appropriate.
I considered retaining a prefix_filename_unsafe() for cases
where we know the static lifetime is OK (and handling the
cleanup is awkward). This is only a handful of cases,
though, and it's not worth the mental energy in worrying
about whether the "unsafe" variant is OK to use in any
situation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
