use DIV_ROUND_UP

Convert code that divides and rounds up to use DIV_ROUND_UP to make the
intent clearer and reduce the number of magic constants.

Signed-off-by: Rene Scharfe <redacted>
Reviewed-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Sync with maint

Prepare for 2.13.3

Merge branch 'sb/merge-recursive-code-cleanup' into maint

Code clean-up.

* sb/merge-recursive-code-cleanup:
  merge-recursive: use DIFF_XDL_SET macro

Merge branch 'jc/utf8-fprintf' into maint

Code cleanup.

* jc/utf8-fprintf:
  submodule--helper: do not call utf8_fprintf() unnecessarily

Merge branch 'js/fsck-name-object' into maint

Test fix.

* js/fsck-name-object:
  t1450: use egrep for regexp "alternation"

Merge branch 'js/t5534-rev-parse-gives-multi-line-output-fix' into maint

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

Merge branch 'ab/sha1dc-maint' into maint

Update the sha1dc again to fix portability glitches.

* ab/sha1dc-maint:
  sha1dc: update from upstream

Merge branch 'aw/contrib-subtree-doc-asciidoctor' into maint

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

Merge branch 'cc/shared-index-permfix' into maint

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

Merge branch 'ah/doc-pretty-color-auto-prefix' into maint

Doc update.

* ah/doc-pretty-color-auto-prefix:
  doc: clarify syntax for %C(auto,...) in pretty formats

Merge branch 'mb/reword-autocomplete-message' into maint

Message update.

* mb/reword-autocomplete-message:
  auto-correct: tweak phrasing

Merge branch 'ks/t7508-indent-fix' into maint

Cosmetic update to a test.

* ks/t7508-indent-fix:
  t7508: fix a broken indentation

Merge branch 'sb/t4005-modernize' into maint

Test clean-up.

* sb/t4005-modernize:
  t4005: modernize style and drop hard coded sha1

Merge branch 'rs/apply-validate-input' into maint

Tighten error checks for invalid "git apply" input.

* rs/apply-validate-input:
  apply: check git diffs for mutually exclusive header lines
  apply: check git diffs for invalid file modes
  apply: check git diffs for missing old filenames

Merge branch 'jc/pack-bitmap-unaligned' into maint

An unaligned 32-bit access in pack-bitmap code ahs been corrected.

* jc/pack-bitmap-unaligned:
  pack-bitmap: don't perform unaligned memory access

Merge branch 'pw/rebase-i-regression-fix-tests' into maint

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

Merge branch 'jk/add-p-commentchar-fix' into maint

"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

Merge branch 'js/alias-early-config' into maint

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

Merge branch 'rs/pretty-add-again' into maint

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

Merge branch 'ah/doc-gitattributes-empty-index' into maint

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

Merge branch 'da/mergetools-meld-output-opt-on-macos' into maint

"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

Merge branch 'jk/diff-highlight-module' into maint

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

Sixteenth batch for 2.14

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'jk/reflog-walk-maint'

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

Merge branch 'bb/unicode-10.0'

Update the character width tables.

* bb/unicode-10.0:
  unicode: update the width tables to Unicode 10

Merge branch 'ks/typofix-commit-c-comment'

Typofix.

* ks/typofix-commit-c-comment:
  builtin/commit.c: fix a typo in the comment

Merge branch 'ab/wildmatch'

Minor code cleanup.

* ab/wildmatch:
  wildmatch: remove unused wildopts parameter

Merge branch 'ab/sha1dc'

The "collission-detecting" implementation of SHA-1 hash we borrowed
from is replaced by directly binding the upstream project as our
submodule.  Glitches on minority platforms are still being worked out.

* ab/sha1dc:
  sha1collisiondetection: automatically enable when submodule is populated
  sha1dc: optionally use sha1collisiondetection as a submodule

Merge branch 'rs/free-and-null'

Code cleanup.

* rs/free-and-null:
  coccinelle: polish FREE_AND_NULL rules

Merge branch 'pw/unquote-path-in-git-pm'

Code refactoring.

* pw/unquote-path-in-git-pm:
  t9700: add tests for Git::unquote_path()
  Git::unquote_path(): throw an exception on bad path
  Git::unquote_path(): handle '\a'
  add -i: move unquote_path() to Git.pm

Merge branch 'ks/commit-assuming-only-warning-removal'

An old message shown in the commit log template was removed, as it
has outlived its usefulness.

* ks/commit-assuming-only-warning-removal:
  commit-template: distinguish status information unconditionally
  commit-template: remove outdated notice about explicit paths

ref-filter.c: drop return from void function

Sun's C compiler errors out on this pattern:

void foo() { ... }
void bar() { return foo(); }

Signed-off-by: Alejandro R. Sedeño <redacted>
Signed-off-by: Junio C Hamano <redacted>

l10n: de.po: fix typo

Reported-by: Andre Hinrichs <redacted>
Signed-off-by: Ralf Thielow <redacted>
Signed-off-by: Junio C Hamano <redacted>

Makefile: disable unaligned loads with UBSan

The undefined behavior sanitizer complains about unaligned
loads, even if they're OK for a particular platform in
practice. It's possible that they _are_ a problem, of
course, but since it's a known tradeoff the UBSan errors are
just noise.

Let's quiet it automatically by building with
NO_UNALIGNED_LOADS when SANITIZE=undefined is in use.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Makefile: turn off -fomit-frame-pointer with sanitizers

The ASan manual recommends disabling this optimization, as
it can make the backtraces produced by the tool harder to
follow (and since this is a test-debug build, we don't care
about squeezing out every last drop of performance).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Makefile: add helper for compiling with -fsanitize

You can already build and test with ASan by doing:

  make CFLAGS=-fsanitize=address test

but there are a few slight annoyances:

  1. It's a little long to type.

  2. It override your CFLAGS completely. You'd probably
     still want -O2, for instance.

  3. It's a good idea to also turn off "recovery", which
     lets the program keep running after a problem is
     detected (with the intention of finding as many bugs as
     possible in a given run). Since Git's test suite should
     generally run without triggering any problems, it's
     better to abort immediately and fail the test when we
     do find an issue.

With this patch, all of that happens automatically when you
run:

  make SANITIZE=address test

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

test-lib: turn on ASan abort_on_error by default

By default, ASan will exit with code 1 when it sees an
error. This means we'll notice a problem when we expected
git to succeed, but not in a test_must_fail block.

Let's ask it to actually raise SIGABRT instead. That will
give us a signal death that test_must_fail will notice. As a
bonus, it may also leave a coredump, which can be handy for
digging into a failure.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

test-lib: set ASAN_OPTIONS variable before we run git

We turn off ASan's leak detection by default in the test
suite because it's too noisy. But we don't do so until
part-way through test-lib. This is before we've run any
tests, but after we do our initial "./git" to see if the
binary has even been built.

When built with clang, this seems to work fine. However,
using "gcc -fsanitize=address", the leak checker seems to
complain more aggressively:

  $ ./git
  ...
  ==5352==ERROR: LeakSanitizer: detected memory leaks
  Direct leak of 2 byte(s) in 1 object(s) allocated from:
      #0 0x7f120e7afcf8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1cf8)
      #1 0x559fc2a3ce41 in do_xmalloc /home/peff/compile/git/wrapper.c:60
      #2 0x559fc2a3cf1a in do_xmallocz /home/peff/compile/git/wrapper.c:100
      #3 0x559fc2a3d0ad in xmallocz /home/peff/compile/git/wrapper.c:108
      #4 0x559fc2a3d0ad in xmemdupz /home/peff/compile/git/wrapper.c:124
      #5 0x559fc2a3d0ad in xstrndup /home/peff/compile/git/wrapper.c:130
      #6 0x559fc274535a in main /home/peff/compile/git/common-main.c:39
      #7 0x7f120dabd2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)

This is a leak in the sense that we never free it, but it's
in a global that is meant to last the whole program. So it's
not really interesting or in need of fixing. And at any
rate, mentioning leaks outside of the test_expect blocks is
certainly unwelcome, as it pollutes stderr.

Let's bump the setting of ASAN_OPTIONS higher in test-lib.sh
to catch our initial "can we even run git?" test.  While
we're at it, we can add a comment to make it a bit less
inscrutable.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

doc: correct a mistake in an illustration

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 <redacted>
Signed-off-by: Junio C Hamano <redacted>

wt-status: use separate variable for result of shorten_unambiguous_ref

Store the pointer to the string allocated by shorten_unambiguous_ref in
a dedicated variable, short_base, and keep base unchanged.  A non-const
variable is more appropriate for such an object.  It avoids having to
cast const away on free and stops redefining the meaning of base, making
the code slightly clearer.

Signed-off-by: Rene Scharfe <redacted>
Reviewed-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

reflog-walk: apply --since/--until to reflog dates

When doing a reflog walk, we use the commit's date to
do any date limiting. In earlier versions of Git, this could
lead to nonsense results, since a skipped commit would
truncate the traversal. So a sequence like:

  git commit ...
  git checkout week-old-branch
  git checkout -
  git log -g --since=1.day.ago

would stop at the week-old-branch, even though the "git
commit" entry further back is still interesting.

As of the prior commit, which uses a parent-less traversal
of the reflog, you get the whole reflog minus any commits
whose dates do not match the specified options. This is
arguably useful, as you could scan the reflogs for commits
that originated in a certain range.

But more likely a user doing a reflog walk wants to limit
based on the reflog entries themselves. You can simulate
--until with:

  git log -g @{1.day.ago}

but there's no way to ask Git to traverse only back to a
certain date. E.g.:

  # show me reflog entries from the past day
  git log -g --since=1.day.ago

This patch teaches the revision machinery to prefer the
reflog entry dates to the commit dates when doing a reflog
walk. Technically this is a change in behavior that affects
plumbing, but the previous behavior was so buggy that it's
unlikely anyone was relying on it.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

reflog-walk: stop using fake parents

The reflog-walk system works by putting a ref's tip into the
pending queue, and then "traversing" the reflog by
pretending that the parent of each commit is the previous
reflog entry.

This causes a number of user-visible oddities, as documented
in t1414 (and the commit message which introduced it). We
can fix all of them in one go by replacing the fake-reflog
system with a much simpler one: just keeping a list of
reflogs to show, and walking through them entry by entry.

The implementation is fairly straight-forward, but there are
a few items to note:

  1. We obviously must skip calling add_parents_to_list()
     when we are traversing reflogs, since we do not want to
     walk the original parents at all.  As a result, we must call
     try_to_simplify_commit() ourselves.

     There are other parts of add_parents_to_list() we skip,
     as well, but none of them should matter for a reflog
     traversal:

       -  We do not allow UNINTERESTING commits, nor
          symmetric ranges (and we bail when these are used
          with "-g").

       - Using --source makes no sense, since we aren't
         traversing. The reflog selector shows the same
         information with more detail.

       - Using --first-parent is still sensible, since you
         may want to see the first-parent diff for each
         entry. But since we're not traversing, we don't
         need to cull the parent list here.

  2. Since we now just walk the reflog entries themselves,
     rather than starting with the ref tip, we now look at
     the "new" field of each entry rather than the "old"
     (i.e., we are showing entries, not faking parents).
     This removes all of the tricky logic around skipping
     past root commits.

     But note that we have no way to show an entry with the
     null sha1 in its "new" field (because such a commit
     obviously does not exist). Normally this would not
     happen, since we delete reflogs along with refs, but
     there is one special case. When we rename the currently
     checked out branch, we write two reflog entries into
     the HEAD log: one where the commit goes away, and
     another where it comes back.

     Prior to this commit, we show both entries with
     identical reflog messages. After this commit, we show
     only the "comes back" entry. See the update in t3200
     which demonstrates this.

     Arguably either is fine, as the whole double-entry
     thing is a bit hacky in the first place. And until a
     recent fix, we truncated the traversal in such a case
     anyway, which was _definitely_ wrong.

  3. We show individual reflogs in order, but choose which
     reflog to show at each stage based on which has the
     most recent timestamp.  This interleaves the output
     from multiple reflogs based on date order, which is
     probably what you'd want with limiting like "-n 30".

     Note that the implementation aims for simplicity. It
     does a linear walk over the reflog queue for each
     commit it pulls, which may perform badly if you
     interleave an enormous number of reflogs. That seems
     like an unlikely use case; if we did want to handle it,
     we could probably keep a priority queue of reflogs,
     ordered by the timestamp of their current tip entry.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

rev-list: check reflog_info before showing usage

When git-rev-list sees no pending commits, it shows a usage
message. This works even when reflog-walking is requested,
because the reflog-walk code currently puts the reflog tips
into the pending queue.

In preparation for refactoring the reflog-walk code, let's
explicitly check whether we have any reflogs to walk. For
now this is a noop, but the existing reflog tests will make
sure that it kicks in after the refactoring. Likewise, we'll
add a test that "rev-list -g" without specifying any reflogs
continues to fail (so that we know our check does not kick
in too aggressively).

Note that the implementation needs to go into its own
sub-function, as the walk code does not expose its innards
outside of reflog-walk.c.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

get_revision_1(): replace do-while with an early return

The get_revision_1() function tries to avoid entering its
main loop at all when there are no commits to look at. But
it's perfectly safe to call pop_commit() on an empty list
(in which case it will return NULL). Switching to an early
return from the loop lets us skip repeating the loop
condition before we enter the do-while. That will get more
important when we start pulling reflog-walk commits from a
source besides the revs->commits queue, as that condition
will get much more complicated.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

log: do not free parents when walking reflog

When we're doing a reflog walk (instead of walking the
actual parent pointers), we may see commits multiple times.
For this reason, we hold on to the commit buffer for each
commit rather than freeing it after we've showed the commit.

We should do the same for the parent list. Right now this is
just a minor optimization. But once we refactor how reflog
walks are performed, keeping the parents will avoid
confusing us the second time we see the commit.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

log: clarify comment about reflog cycles

When we're walking reflogs, we leave the commit buffer and
parents in place. A comment explains that this is due to
"cycles". But the interesting thing is the unsaid
implication: that the cycles (plus our clearing of the SEEN
flag) will cause us to show commits multiple times. Let's
spell it out.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

progress: show overall rate in last update

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 <redacted>
Signed-off-by: Rene Scharfe <redacted>
Signed-off-by: Junio C Hamano <redacted>

urlmatch: use hex2chr() in append_normalized_escapes()

Simplify the code by using hex2chr() to convert and check for invalid
characters at the same time instead of doing that sequentially with
one table lookup for each.

Signed-off-by: Rene Scharfe <redacted>
Signed-off-by: Junio C Hamano <redacted>

apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

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 <redacted>
Signed-off-by: Junio C Hamano <redacted>

branch: set remote color in ref-filter branch immediately

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 <redacted>
Signed-off-by: Junio C Hamano <redacted>

branch: use BRANCH_COLOR_LOCAL in ref-filter format

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 <redacted>
Signed-off-by: Junio C Hamano <redacted>

branch: only perform HEAD check for local branches

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 <redacted>
Signed-off-by: Junio C Hamano <redacted>

unicode: update the width tables to Unicode 10

Now that Unicode 10 has been announced[0], update the character
width tables to the new version.

[0] http://blog.unicode.org/2017/06/announcing-unicode-standard-version-100.html

Signed-off-by: Beat Bolli <redacted>
Signed-off-by: Junio C Hamano <redacted>

revision: disallow reflog walking with revs->limited

The reflog-walk code doesn't work with limit_list().  That
function traverses down the real history graph, not the fake
reflog history that get_revision() returns. So it's not
going to actually examine all of the commits we're going to
show, because we'd add them to the pending list only during
the actual traversal.

In practice this limitation doesn't really matter, because
the options that require list-limiting generally need
UNINTERESTING endpoints or symmetric ranges, which already
are forbidden for reflog walks. Still, there are likely some
corner cases that would behave oddly. We're better off to
warn the user that we can't fulfill their request than to
generate potentially wrong output.

This will also make it easier to refactor the reflog-walking
code, because it eliminates a whole area of corner cases
we'd have to consider (that already don't work anyway).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

t1414: document some reflog-walk oddities

Since its inception, the general strategy of the reflog-walk
code has been to start with the tip commit for the ref, and
as we traverse replace each commit's parent pointers with
fake parents pointing to the previous reflog entry.

This lets us traverse the reflog as if it were a real
history, but it has some user-visible oddities. Namely:

  1. The fake parents are used for commit selection and
     display. So for example, "--merges" or "--no-merges"
     are not useful, because the history appears as a linear
     string of commits. Likewise, pathspec limiting is based
     on the diff between adjacent entries, not the changes
     actually introduced by a commit.

     These are often the same (e.g., because the entry was
     just running "git commit" and the adjacent entry _is_
     the true parent), but it may not be in several common
     cases. For instance, using "git reset" to jump around
     history, or "git checkout" to move HEAD.

  2. We reverse-map each commit back to its reflog. So when
     it comes time to show commit X, we say "a-ha, we added
     X because it was at the tip of the 'foo' reflog, so
     let's show the foo reflog". But this leads to nonsense
     results when you ask to traverse multiple reflogs: if
     two reflogs have the same tip commit, we only map back
     to one of them.  Instead, we should show both.

  3. If the tip of the reflog and the ref tip disagree on
     the current value, we show the ref tip but give no
     indication of the value in the reflog.  This situation
     isn't supposed to happen (since any ref update should
     touch the reflog). But if it does, given that the
     requested operation is to show the reflog, it makes
     sense to prefer that.

This commit adds a new script with several expect_failure
tests to demonstrate the problems.  This could be part of
the existing t1411, but it's a bit easier to start from a
fresh state, where we know exactly what will be in the log.

Since the new multiple-reflog tests are checking the actual
output, we can drop the "make sure we don't segfault" tests
from t1411, which are a strict subset of what we're doing
here.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge branch 'jk/reflog-walk-maint' into jk/reflog-walk

* 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

reflog-walk: include all fields when freeing complete_reflogs

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 <redacted>
Signed-off-by: Junio C Hamano <redacted>

reflog-walk: don't free reflogs added to cache

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 <redacted>
Signed-off-by: Junio C Hamano <redacted>

reflog-walk: duplicate strings in complete_reflogs list

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 <redacted>
Signed-off-by: Junio C Hamano <redacted>

Fifteenth batch for 2.14

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'ab/strbuf-addftime-tzname-boolify'

strbuf_addftime() is further getting tweaked.

* ab/strbuf-addftime-tzname-boolify:
  strbuf: change an always NULL/"" strbuf_addftime() param to bool
  strbuf.h comment: discuss strbuf_addftime() arguments in order

Merge branch 'xz/send-email-batch-size'

"git send-email" learned to overcome some SMTP server limitation
that does not allow many pieces of e-mails to be sent over a single
session.

* xz/send-email-batch-size:
  send-email: --batch-size to work around some SMTP server limit

Merge branch 'js/t5534-rev-parse-gives-multi-line-output-fix'

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

Merge branch 'sb/merge-recursive-code-cleanup'

Code clean-up.

* sb/merge-recursive-code-cleanup:
  merge-recursive: use DIFF_XDL_SET macro

Merge branch 'rs/apply-avoid-over-reading'

Code clean-up to fix possible buffer over-reading.

* rs/apply-avoid-over-reading:
  apply: use starts_with() in gitdiff_verify_name()

Merge branch 'ab/sha1dc-maint'

Update the sha1dc again to fix portability glitches.

* ab/sha1dc-maint:
  sha1dc: update from upstream

Merge branch 'jc/utf8-fprintf'

Code cleanup.

* jc/utf8-fprintf:
  submodule--helper: do not call utf8_fprintf() unnecessarily

Merge branch 'js/fsck-name-object'

Test fix.

* js/fsck-name-object:
  t1450: use egrep for regexp "alternation"

Merge branch 'aw/contrib-subtree-doc-asciidoctor'

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

builtin/commit.c: fix a typo in the comment

Signed-off-by: Kaartic Sivaraam <redacted>
Signed-off-by: Junio C Hamano <redacted>

cygwin: allow pushing to UNC paths

 cygwin can use an UNC path like //server/share/repo

 $ cd //server/share/dir
 $ mkdir test
 $ cd test
 $ git init --bare

 However, when we try to push from a local Git repository to this repo,
 there is a problem: Git converts the leading "//" into a single "/".

 As cygwin handles an UNC path so well, Git can support them better:

 - Introduce cygwin_offset_1st_component() which keeps the leading "//",
   similar to what Git for Windows does.

 - Move CYGWIN out of the POSIX in the tests for path normalization in t0060

Signed-off-by: Torsten Bögershausen <redacted>
Signed-off-by: Junio C Hamano <redacted>

t/helper/test-hashmap: use custom data instead of duplicate cmp functions

With the new field that is passed to the compare function, we can pass
through flags there instead of having multiple compare functions.
Also drop the cast to hashmap_cmp_fn.

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

name-hash.c: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

submodule-config.c: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote.c: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

patch-ids.c: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

convert/sub-process: drop cast to hashmap_cmp_fn

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

config.c: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

builtin/describe: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

builtin/difftool.c: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

attr.c: drop hashmap_cmp_fn cast

MAke the code more readable and less error prone by avoiding the cast
of the compare function pointer in hashmap_init, but instead have the
correctly named void pointers to casted to the specific data structure.

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

Fourteenth batch for 2.14

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'jt/unify-object-info'

Code clean-ups.

* jt/unify-object-info:
  sha1_file: refactor has_sha1_file_with_flags
  sha1_file: do not access pack if unneeded
  sha1_file: teach sha1_object_info_extended more flags
  sha1_file: refactor read_object
  sha1_file: move delta base cache code up
  sha1_file: rename LOOKUP_REPLACE_OBJECT
  sha1_file: rename LOOKUP_UNKNOWN_OBJECT
  sha1_file: teach packed_object_info about typename

Merge branch 'cc/shared-index-permfix'

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

Merge branch 'rs/sha1-name-readdir-optim'

Optimize "what are the object names already taken in an alternate
object database?" query that is used to derive the length of prefix
an object name is uniquely abbreviated to.

* rs/sha1-name-readdir-optim:
  sha1_file: guard against invalid loose subdirectory numbers
  sha1_file: let for_each_file_in_obj_subdir() handle subdir names
  p4205: add perf test script for pretty log formats
  sha1_name: cache readdir(3) results in find_short_object_filename()

Merge branch 'bw/repo-object'

Introduce a "repository" object to eventually make it easier to
work in multiple repositories (the primary focus is to work with
the superproject and its submodules) in a single process.

* bw/repo-object:
  ls-files: use repository object
  repository: enable initialization of submodules
  submodule: convert is_submodule_initialized to work on a repository
  submodule: add repo_read_gitmodules
  submodule-config: store the_submodule_cache in the_repository
  repository: add index_state to struct repo
  config: read config from a repository object
  path: add repo_worktree_path and strbuf_repo_worktree_path
  path: add repo_git_path and strbuf_repo_git_path
  path: worktree_git_path() should not use file relocation
  path: convert do_git_path to take a 'struct repository'
  path: convert strbuf_git_common_path to take a 'struct repository'
  path: always pass in commondir to update_common_dir
  path: create path.h
  environment: store worktree in the_repository
  environment: place key repository state in the_repository
  repository: introduce the repository object
  environment: remove namespace_len variable
  setup: add comment indicating a hack
  setup: don't perform lazy initialization of repository state

reflog-walk: skip over double-null oid due to HEAD rename

Since 39ee4c6c2f (branch: record creation of renamed branch
in HEAD's log, 2017-02-20), a rename on the currently
checked out branch will create two entries in the HEAD
reflog: one where the branch goes away (switching to the
null oid), and one where it comes back (switching away from
the null oid).

This confuses the reflog-walk code. When walking backwards,
it first sees the null oid in the "old" field of the second
entry. Thanks to the "root commit" logic added by 71abeb753f
(reflog: continue walking the reflog past root commits,
2016-06-03), we keep looking for the next entry by scanning
the "new" field from the previous entry. But that field is
also null! We need to go just a tiny bit further, and look
at its "old" field. But with the current code, we decide the
reflog has nothing else to show and just give up. To the
user this looks like the reflog was truncated by the rename
operation, when in fact those entries are still there.

This patch does the absolute minimal fix, which is to look
back that one extra level and keep traversing.

The resulting behavior may not be the _best_ thing to do in
the long run (for example, we show both reflog entries each
with the same commit id), but it's a simple way to fix the
problem without risking further regressions.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5534: fix misleading grep invocation

It seems to be a little-known feature of `grep` (and it certainly came
as a surprise to this here developer who believed to know the Unix tools
pretty well) that multiple patterns can be passed in the same
command-line argument simply by separating them by newlines. Watch, and
learn:

$ printf '1\n2\n3\n' | grep "$(printf '1\n3\n')"
1
3

That behavior also extends to patterns passed via `-e`, and it is not
modified by passing the option `-E` (but trying this with -P issues the
error "grep: the -P option only supports a single pattern").

It seems that there are more old Unix hands who are surprised by this
behavior, as grep invocations of the form

grep "$(git rev-parse A B) C" file

were introduced in a85b377d041 (push: the beginning of "git push
--signed", 2014-09-12), and later faithfully copy-edited in b9459019bbb
(push: heed user.signingkey for signed pushes, 2014-10-22).

Please note that the output of `git rev-parse A B` separates the object
IDs via *newlines*, not via spaces, and those newlines are preserved
because the interpolation is enclosed in double quotes.

As a consequence, these tests try to validate that the file contains
either A's object ID, or B's object ID followed by C, or both. Clearly,
however, what the test wanted to see is that there is a line that
contains all of them.

This is clearly unintended, and the grep invocations in question really
match too many lines.

Fix the test by avoiding the newlines in the patterns.

Signed-off-by: Johannes Schindelin <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: --batch-size to work around some SMTP server limit

Some email servers (e.g. smtp.163.com) limit the number emails to be
sent per session (connection) and this will lead to a faliure when
sending many messages.

Teach send-email to disconnect after sending a number of messages
(configurable via the --batch-size=<num> option), wait for a few
seconds (configurable via the --relogin-delay=<seconds> option) and
reconnect, to work around such a limit.

Also add two configuration variables to give these options the default.

Note:

  We will use this as a band-aid for now, but in the longer term, we
  should look at and react to the SMTP error code from the server;
  Xianqiang reports that 450 and 451 are returned by problematic
  servers.

  cf. https://public-inbox.org/git/7993e188.d18d.15c3560bcaf.Coremail.zxq_yx_007@163.com/

Signed-off-by: xiaoqiang zhao <redacted>
Signed-off-by: Junio C Hamano <redacted>

sha1collisiondetection: automatically enable when submodule is populated

If a user wants to experiment with the version of collision
detecting sha1 from the submodule, the user needed to not just
populate the submodule but also needed to turn the knob.

A Makefile trick is easy enough to do so, so let's do this.  When
somebody with a copy of the submodule populated wants not to use it,
that can be done by overriding it in config.mak or from the command
line.

Signed-off-by: Junio C Hamano <redacted>
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
Signed-off-by: Junio C Hamano <redacted>

sha1dc: optionally use sha1collisiondetection as a submodule

Add an option to use the sha1collisiondetection library from the
submodule in sha1collisiondetection/ instead of in the copy in the
sha1dc/ directory.

This allows us to try out the submodule in sha1collisiondetection
without breaking the build for anyone who's not expecting them as we
work out any kinks.

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
Signed-off-by: Junio C Hamano <redacted>

sha1dc: update from upstream

Update sha1dc from the latest version by the upstream maintainer[1].

See commit 6b851e536b ("sha1dc: update from upstream", 2017-06-06) for
the last update.

This solves the Big Endian detection on Solaris reported against
v2.13.2[2], hopefully without any regressions. A version of this has
been tested on two Solaris SPARC installations, Cygwin (by jturney on
cygwin@Freenode), and on numerous more boring systems (mainly
linux/x86_64). See [3] for a discussion of the implementation and
platform-specific issues.

See commit a0103914c2 ("sha1dc: update from upstream", 2017-05-20) and
6b851e536b ("sha1dc: update from upstream", 2017-06-06) for previous
attempts in the 2.13 series to address various compile-time feature
detection in this library.

1. https://github.com/cr-marcstevens/sha1collisiondetection/commit/19d97bf5af05312267c2e874ee6bcf584d9e9681
2. <redacted>
   (https://public-inbox.org/git/CAKKM46tHq13XiW5C8sux3=PZ1VHSu_npG8ExfWwcPD7rkZkyRQ@mail.gmail.com/)
3. https://github.com/cr-marcstevens/sha1collisiondetection/pull/34

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
Signed-off-by: Junio C Hamano <redacted>

read_packed_refs(): die if `packed-refs` contains bogus data

The old code ignored any lines that it didn't understand, including
unterminated lines. This is dangerous. Instead, `die()` if the
`packed-refs` file contains any unterminated lines or lines that we
don't know how to handle.

This fixes the tests added in the last commit.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

t3210: add some tests of bogus packed-refs file contents

If `packed-refs` contains indecipherable lines, we should emit an
error and quit rather than just skipping the lines. Unfortunately, we
currently do the latter. Add some failing tests demonstrating the
problem.

This will be fixed in the next commit.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

repack_without_refs(): don't lock or unlock the packed refs

Change `repack_without_refs()` to expect the packed-refs lock to be
held already, and not to release the lock before returning. Change the
callers to deal with lock management.

This change makes it possible for callers to hold the packed-refs lock
for a longer span of time, a possibility that will eventually make it
possible to fix some longstanding races.

The only semantic change here is that `repack_without_refs()` used to
forget to release the lock in the `if (!removed)` exit path. That
omission is now fixed.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

strbuf: change an always NULL/"" strbuf_addftime() param to bool

strbuf_addftime() allows callers to pass a time zone name for
expanding %Z. The only current caller either passes the empty string
or NULL, in which case %Z is handed over verbatim to strftime(3).
Replace that string parameter with a flag controlling whether to
remove %Z from the format specification. This simplifies the code.

Commit-message-by: René Scharfe <redacted>
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
Signed-off-by: Junio C Hamano <redacted>

apply: use starts_with() in gitdiff_verify_name()

Avoid running over the end of line -- a C string whose length is not
known to this function -- by using starts_with() instead of memcmp(3)
for checking if it starts with "/dev/null".  Also simply include the
newline in the string constant to compare against.  Drop a comment that
just states the obvious.

Signed-off-by: Rene Scharfe <redacted>
Signed-off-by: Junio C Hamano <redacted>

diff: document the new --color-moved setting

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

diff.c: add dimming to moved line detection

Any lines inside a moved block of code are not interesting. Boundaries
of blocks are only interesting if they are next to another block of moved
code.

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>