Code clean-up, that makes us in sync with Debian by one patch.
* jn/hooks-pre-rebase-sample-fix:
pre-rebase hook: capture documentation in a <<here document
The progress meter did not give a useful output when we haven't had
0.5 seconds to measure the throughput during the interval. Instead
show the overall throughput rate at the end, which is a much more
useful number.
* rs/progress-overall-throughput-at-the-end:
progress: show overall rate in last update
On Cygwin, similar to Windows, "git push //server/share/repository"
ought to mean a repository on a network share that can be accessed
locally, but this did not work correctly due to stripping the double
slashes at the beginning.
This may need to be heavily tested before it gets unleashed to the
wild, as the change is at a fairly low-level code and would affect
not just the code to decide if the push destination is local. There
may be unexpected fallouts in the path normalization.
* tb/push-to-cygwin-unc-path:
cygwin: allow pushing to UNC paths
Code cleanup.
* rs/apply-avoid-over-reading:
apply: use strcmp(3) for comparing strings in gitdiff_verify_name()
apply: use starts_with() in gitdiff_verify_name()
A recent update broke an alias that contained an uppercase letter.
* js/alias-case-sensitivity:
alias: compare alias name *case-insensitively*
t1300: demonstrate that CamelCased aliases regressed
FD_CLOEXEC only applies to the file descriptor, so it needs to be
manipuluated via F_GETFD/F_SETFD. F_GETFL/F_SETFL are for file
description flags.
Verified via strace with o_cloexec set to zero.
Signed-off-by: Eric Wong <e@80x24.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is totally legitimate to add CamelCased aliases, but due to the way
config keys are compared, the case does not matter.
Therefore, we must compare the alias name insensitively to the config
keys.
This fixes a regression introduced by a9bcf6586d (alias: use
the early config machinery to expand aliases, 2017-06-14).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is totally legitimate to add CamelCased aliases, but due to the way
config keys are compared, the case does not matter.
Except that now it does: the alias name is expected to be all
lower-case. This is a regression introduced by a9bcf6586d (alias: use
the early config machinery to expand aliases, 2017-06-14).
Noticed by Alejandro Pauly, diagnosed by Kevin Willford.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rewrite of "git branch --list" using for-each-ref's internals
that happened in v2.13 regressed its handling of color.branch.local;
this has been fixed.
* kn/ref-filter-branch-list:
ref-filter.c: drop return from void function
branch: set remote color in ref-filter branch immediately
branch: use BRANCH_COLOR_LOCAL in ref-filter format
branch: only perform HEAD check for local branches
After "git branch --move" of the currently checked out branch, the
code to walk the reflog of HEAD via "log -g" and friends
incorrectly stopped at the reflog entry that records the renaming
of the branch.
* jk/reflog-walk-maint:
reflog-walk: include all fields when freeing complete_reflogs
reflog-walk: don't free reflogs added to cache
reflog-walk: duplicate strings in complete_reflogs list
reflog-walk: skip over double-null oid due to HEAD rename
Without this change, the sample hook does not pass a syntax check
(sh -n):
$ sh -n hooks--pre-rebase.sample
hooks--pre-rebase.sample: line 101: syntax error near unexpected token `('
hooks--pre-rebase.sample: line 101: ` merged into it again (either directly or indirectly).'
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A few tests that tried to verify the contents of push certificates
did not use 'git rev-parse' to formulate the line to look for in
the certificate correctly.
* js/t5534-rev-parse-gives-multi-line-output-fix:
t5534: fix misleading grep invocation
The Makefile rule in contrib/subtree for building documentation
learned to honour USE_ASCIIDOCTOR just like the main documentation
set does.
* aw/contrib-subtree-doc-asciidoctor:
subtree: honour USE_ASCIIDOCTOR when set
The split index code did not honor core.sharedrepository setting
correctly.
* cc/shared-index-permfix:
t1700: make sure split-index respects core.sharedrepository
t1301: move modebits() to test-lib-functions.sh
read-cache: use shared perms when writing shared index
Fix a recent regression to "git rebase -i" and add tests that would
have caught it and others.
* pw/rebase-i-regression-fix-tests:
t3420: fix under GETTEXT_POISON build
rebase: add more regression tests for console output
rebase: add regression tests for console output
rebase -i: add test for reflog message
sequencer: print autostash messages to stderr
"git add -p" were updated in 2.12 timeframe to cope with custom
core.commentchar but the implementation was buggy and a
metacharacter like $ and * did not work.
* jk/add-p-commentchar-fix:
add--interactive: quote commentChar regex
add--interactive: handle EOF in prompt_yesno
The code to pick up and execute command alias definition from the
configuration used to switch to the top of the working tree and
then come back when the expanded alias was executed, which was
unnecessarilyl complex. Attempt to simplify the logic by using the
early-config mechanism that does not chdir around.
* js/alias-early-config:
alias: use the early config machinery to expand aliases
t7006: demonstrate a problem with aliases in subdirectories
t1308: relax the test verifying that empty alias values are disallowed
help: use early config when autocorrecting aliases
config: report correct line number upon error
discover_git_directory(): avoid setting invalid git_dir
The pretty-format specifiers like '%h', '%t', etc. had an
optimization that no longer works correctly. In preparation/hope
of getting it correctly implemented, first discard the optimization
that is broken.
* rs/pretty-add-again:
pretty: recalculate duplicate short hashes
An example in documentation that does not work in multi worktree
configuration has been corrected.
* ah/doc-gitattributes-empty-index:
doc: do not use `rm .git/index` when normalizing line endings
"git mergetool" learned to work around a wrapper MacOS X adds
around underlying meld.
* da/mergetools-meld-output-opt-on-macos:
mergetools/meld: improve compatibiilty with Meld on macOS X
The 'diff-highlight' program (in contrib/) has been restructured
for easier reuse by an external project 'diff-so-fancy'.
* jk/diff-highlight-module:
diff-highlight: split code into module
Sun's C compiler errors out on this pattern:
void foo() { ... }
void bar() { return foo(); }
Signed-off-by: Alejandro R. Sedeño <asedeno@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reported-by: Andre Hinrichs <andre.hinrichs@gmx.de>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The first illustration of the "RECOVERING FROM UPSTREAM REBASE"
section in the 'git-rebase' documentation meant to depict that
there are number of commits on the 'master' branch, but it is
longer than the 'master' branch in the following illustrations
by one commit, even though there is no resetting of 'master' to
lose that commit.
Correct it.
Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The values in struct throughput are only updated every 0.5 seconds. If
we're all done before that time span then the final update will show a
rate of 0 bytes/s, which is misleading if some bytes had been handled.
Remember the start time and show the total throughput instead.
And avoid division by zero by enforcing a minimum time span value of 1
(unit: 1/1024th of a second). That makes the resulting rate an
underestimation, but it's closer to the actual value than the currently
shown 0 bytes/s.
Reported-by: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We don't know the length of the C string "another". It could be
shorter than "name", which we compare it to using memchr(3). Call
strcmp(3) instead to avoid running over the end of the former, and
get rid of a strlen(3) call as a bonus.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We set the current and local branch colors at the top of the
build_format() function. Let's do the same for the remote
color. This saves a little bit of repetition, but more
importantly it puts all of the color-setting in the same
place. That makes it easier to see that we are coloring all
possibilities.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 949af0684 (branch: use ref-filter printing APIs,
2017-01-10), git-branch's output is generated by passing a
custom format to the ref-filter code. This format forgot to
pass BRANCH_COLOR_LOCAL, meaning that local branches
(besides the current one) were never colored at all.
We can add it in the %(if) block where we decide whether the
branch is "current" or merely "local". Note that this means
the current/local coloring is either/or. You can't set:
[color "branch"]
local = blue
current = bold
and expect the current branch to be "bold blue". This
matches the pre-949af0684 behavior.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When assembling the ref-filter format to show "git branch"
output, we put the "%(if)%(HEAD)" conditional at the start
of the overall format. But there's no point in checking
whether a remote branch matches HEAD, as it never will.
The check should go inside the local conditional; we
assemble that format inside the "local" strbuf.
By itself, this is just a minor optimization. But in a
future patch, we'll need this refactoring to fix
local-branch coloring.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we encounter an error adding reflogs for a walk, we try
to free any logs we have read. But we didn't free all
fields, meaning that we could in theory leak all of the
"items" array (which would consitute the bulk of the
allocated memory).
This patch adds a helper which frees all of the entries and
uses it as appropriate.
As it turns out, the leak seems impossible to trigger with
the current code. Of the three error paths that free the
complete_reflogs struct, two only kick in when the items
array is empty, and the third was removed entirely in the
previous commit.
So this patch should be a noop in terms of behavior, but it
fixes a potential maintenance headache should anybody add a
new error path and copy the partial-free code. Which is
what happened in 5026b47175 (add_reflog_for_walk: avoid
memory leak, 2017-05-04), though its leaky call was the
third one that was recently removed.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The add_reflog_for_walk() function keeps a cache mapping
refnames to their reflog contents. We use a cached reflog
entry if available, and otherwise allocate and store a new
one.
Since 5026b47175 (add_reflog_for_walk: avoid memory leak,
2017-05-04), when we hit an error parsing a date-based
reflog spec, we free the reflog memory but leave the cache
entry pointing to the now-freed memory.
We can fix this by just leaving the memory intact once it
has made it into the cache. This may leave an unused entry
in the cache, but that's OK. And it means we also catch a
similar situation: we may not have allocated at all in this
invocation, but simply be pointing to a cached entry from a
previous invocation (which is relying on that entry being
present).
The new test in t1411 exercises this case and fails when run
with --valgrind or ASan.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As part of the add_reflog_to_walk() function, we keep a
string_list mapping refnames to their reflog contents. This
serves as a cache so that accessing the same reflog twice
requires only a single copy of the log in memory.
The string_list is initialized via xcalloc, meaning its
strdup_strings field is set to 0. But after inserting a
string into the list, we unconditionally call free() on the
string, leaving the list pointing to freed memory. If
another reflog is added (e.g., "git log -g HEAD HEAD"), then
the second one may have unpredictable results.
The extra free was added by 5026b47175 (add_reflog_for_walk:
avoid memory leak, 2017-05-04). Though if you look
carefully, you can see that the code was buggy even before
then. If we tried to read the reflogs by time but came up
with no entries, we exited with an error, freeing the string
in that code path. So the bug was harder to trigger, but
still there.
We can fix it by just asking the string list to make a copy
of the string. Technically we could fix the problem by not
calling free() on our string (and just handing over
ownership to the string list), but there are enough
conditionals that it's quite hard to figure out which code
paths need the free and which do not. Simpler is better
here.
The new test reliably shows the problem when run with
--valgrind or ASAN.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
