The error message from "git blame --contents --reverse" incorrectly
talked about "--contents --children".

* mk/blame-error-message:
  blame: fix option name in error message

"git merge-file" tried to signal how many conflicts it found, which
obviously would not work well when there are too many of them.

* jk/merge-file-exit-code:
  merge-file: clamp exit code to maximum 127

The name-hash subsystem that is used to cope with case insensitive
filesystems keeps track of directories and their on-filesystem
cases for all the paths in the index by holding a pointer to a
randomly chosen cache entry that is inside the directory (for its
ce->ce_name component).  This pointer was not updated even when the
cache entry was removed from the index, leading to use after free.
This was fixed by recording the path for each directory instead of
borrowing cache entries and restructuring the API somewhat.

* dt/name-hash-dir-entry-fix:
  name-hash: don't reuse cache_entry in dir_entry

"git am -3" had a small regression where it is aborted in its error
handling codepath when underlying merge-recursive failed in certain
ways, as it assumed that the internal call to merge-recursive will
never die, which is not the case (yet).

* jc/am-3-fallback-regression-fix:
  am -3: do not let failed merge from completing the error codepath

The synopsis text and the usage string of subcommands that read
list of things from the standard input are often shown as if they
only take input from a file on a filesystem, which was misleading.

* jc/usage-stdin:
  usage: do not insist that standard input must come from a file

A couple of commands still showed "[options]" in their usage string
to note where options should come on their command line, but we
spell that "[<options>]" in most places these days.

* rt/placeholder-in-usage:
  am, credential-cache: add angle brackets to usage string

* dt/t7063-fix-flaky-test:
  t7063: fix flaky untracked-cache test

The submodule code has been taught to work better with separate
work trees created via "git worktree add".

* mk/submodule-gitdir-path:
  path: implement common_dir handling in git_pathdup_submodule()
  submodule refactor: use strbuf_git_path_submodule() in add_submodule_odb()

When "git gc --auto" is backgrounded, its diagnosis message is
lost.  Save it to a file in $GIT_DIR and show it next time the "gc
--auto" is run.

* nd/gc-auto-background-fix:
  gc: save log from daemonized gc --auto and print it next time

Work around "git p4" failing when the P4 depot records the contents
in UTF-16 without UTF-16 BOM.

* ls/p4-translation-failure:
  git-p4: handle "Translation of file content failed"
  git-p4: add test case for "Translation of file content failed" error

Recent update to "rebase -i" that tries to sanity check the edited
insn sheet before it uses it has become too picky on Windows where
CRLF left by the editor is turned into a trailing CR on the line
read via the "read" built-in command.

* gr/rebase-i-drop-warn:
  rebase-i: work around Windows CRLF line endings
  t3404: "rebase -i" gets broken when insn sheet uses CR/LF line endings

"git clone --dissociate" runs a big "git repack" process at the
end, and it helps to close file descriptors that are open on the
packs and their idx files before doing so on filesystems that
cannot remove a file that is still open.

* js/clone-dissociate:
  clone --dissociate: avoid locking pack files
  sha1_file.c: add a function to release all packs
  sha1_file: consolidate code to close a pack's file descriptor
  t5700: demonstrate a Windows file locking issue with `git clone --dissociate`

Correct "git p4 --detect-labels" so that it does not fail to create
a tag that points at a commit that is also being imported.

* ld/p4-import-labels:
  git-p4: fix P4 label import for unprocessed commits
  git-p4: do not terminate creating tag for unknown commit
  git-p4: failing test for ignoring invalid p4 labels

The internal stripspace() function has been moved to where it
logically belongs to, i.e. strbuf API, and the command line parser
of "git stripspace" has been updated to use the parse_options API.

* tk/stripspace:
  stripspace: use parse-options for command-line parsing
  strbuf: make stripspace() part of strbuf

Prepare for Git on-disk repository representation to undergo
backward incompatible changes by introducing a new repository
format version "1", with an extension mechanism.

* jk/repository-extension:
  introduce "preciousObjects" repository extension
  introduce "extensions" form of core.repositoryformatversion

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

"git daemon" uses "run_command()" without "finish_command()", so it
needs to release resources itself, which it forgot to do.

* rs/daemon-plug-child-leak:
  daemon: plug memory leak
  run-command: factor out child_process_clear()

"git blame" learnt to take "--first-parent" and "--reverse" at the
same time when it makes sense.

* mk/blame-first-parent:
  blame: allow blame --reverse --first-parent when it makes sense
  blame: extract find_single_final
  blame: test to describe use of blame --reverse --first-parent

"git status --branch --short" accessed beyond the constant string
"HEAD", which has been corrected.

* rs/wt-status-detached-branch-fix:
  wt-status: use skip_prefix() to get rid of magic string length constants
  wt-status: don't skip a magical number of characters blindly
  wt-status: avoid building bogus branch name with detached HEAD
  wt-status: exit early using goto in wt_shortstatus_print_tracking()
  t7060: add test for status --branch on a detached HEAD

Code simplification.

* rs/show-branch-argv-array:
  show-branch: use argv_array for default arguments

Allow easier debugging of a single "git" invocation in our test
scripts.

* js/git-gdb:
  test: facilitate debugging Git executables in tests with gdb

We peek objects from submodule's object store by linking it to the
list of alternate object databases, but the code to do so forgot to
correctly initialize the list.

* jk/initialization-fix-to-add-submodule-odb:
  add_submodule_odb: initialize alt_odb list earlier

The code to prepare the working tree side of temporary directory
for the "dir-diff" feature forgot that symbolic links need not be
copied (or symlinked) to the temporary area, as the code already
special cases and overwrites them.  Besides, it was wrong to try
computing the object name of the target of symbolic link, which may
not even exist or may be a directory.

* da/difftool:
  difftool: ignore symbolic links in use_wt_file

Hotfix for a topic already in 'master'.

* jc/mailinfo-lib:
  mailinfo: fix passing wrong address to git_mailinfo_config

Using the timestamp based criteria in "git branch --sort" did not
tiebreak branches that point at commits with the same timestamp (or
the same commit), making the resulting output unstable.

* kn/for-each-branch:
  ref-filter: fallback on alphabetical comparison

Call child_process_clear() when a child ends to release the memory
allocated for its environment.  This is necessary because unlike all
other users of start_command() we don't call finish_command(), which
would have taken care of that for us.

This leak was introduced by f063d38b (daemon: use cld->env_array
when re-spawning).
Signed-off-by: NRene Scharfe <l.s.r@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Avoid duplication by moving the code to release allocated memory for
arguments and environment to its own function, child_process_clear().
Export it to provide a counterpart to child_process_init().
Signed-off-by: NRene Scharfe <l.s.r@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git_mailinfo_config() expects "struct mailinfo *". But in
setup_mailinfo(), "mi" is already "struct mailinfo *". &mi would make
it "struct mailinfo **" and git_mailinfo_config() would damage some
other memory when it assigns some value to mi->use_scissors.

This is caught by t4150.20. git_mailinfo_config() breaks
mi->name.alloc and makes strbuf_release() in clear_mailinfo() attempt
to free strbuf_slopbuf.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Use argv_array instead of open-coding it.
Signed-off-by: NRene Scharfe <l.s.r@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NRene Scharfe <l.s.r@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Use the variable branch_name, which already has "refs/heads/" removed,
instead of blindly advancing in the ->branch string by 11 bytes.  This
is safer and less magical.
Signed-off-by: NRene Scharfe <l.s.r@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If we're on a detached HEAD then wt_shortstatus_print_tracking() takes
the string "HEAD (no branch)", translates it, skips the first eleven
characters and passes the result to branch_get(), which returns a bogus
result and accesses memory out of bounds in order to produce it.
Somehow stat_tracking_info(), which is passed that result, does the
right thing anyway, i.e. it finds that there is no base.

Avoid the bogus results and memory accesses by checking for HEAD first
and exiting early in that case.  This fixes t7060 with --valgrind.
Signed-off-by: NRene Scharfe <l.s.r@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Deduplicate printing the line terminator by jumping to the end of the
function.
Signed-off-by: NRene Scharfe <l.s.r@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This test fails when run under Valgrind because branch_get() gets passed
a bogus branch name pointer:

==62831== Invalid read of size 1
==62831==    at 0x4F76AE: branch_get (remote.c:1650)
==62831==    by 0x53499E: wt_shortstatus_print_tracking (wt-status.c:1654)
==62831==    by 0x53499E: wt_shortstatus_print (wt-status.c:1706)
==62831==    by 0x428D29: cmd_status (commit.c:1384)
==62831==    by 0x405D6D: run_builtin (git.c:350)
==62831==    by 0x405D6D: handle_builtin (git.c:536)
==62831==    by 0x404F10: run_argv (git.c:582)
==62831==    by 0x404F10: main (git.c:690)
==62831==  Address 0x5e89b0b is 6 bytes after a block of size 5 alloc'd
==62831==    at 0x4C28C4F: malloc (vg_replace_malloc.c:299)
==62831==    by 0x59579E9: strdup (strdup.c:42)
==62831==    by 0x52E108: xstrdup (wrapper.c:43)
==62831==    by 0x5322A6: wt_status_prepare (wt-status.c:130)
==62831==    by 0x4276E0: status_init_config (commit.c:184)
==62831==    by 0x428BB8: cmd_status (commit.c:1350)
==62831==    by 0x405D6D: run_builtin (git.c:350)
==62831==    by 0x405D6D: handle_builtin (git.c:536)
==62831==    by 0x404F10: run_argv (git.c:582)
==62831==    by 0x404F10: main (git.c:690)
Signed-off-by: NRene Scharfe <l.s.r@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Allow combining --reverse and --first-parent if initial commit of
specified range is at the first-parent chain starting from the final
commit. Disable the prepare_revision_walk()'s builtin children
collection, instead picking only the ones which are along the first
parent chain.
Signed-off-by: NMax Kirillov <max@max630.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMax Kirillov <max@max630.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Reverse blame can be used to locate removal of lines which does not
change adjacent lines. Such edits do not appear in non-reverse blame,
because the adjacent lines last changed commit is older history, before
the edit.

For a big and active project which uses topic branches, or analogous
feature, for example pull-requests, the history can contain many
concurrent branches, and even after an edit merged into the target
branch, there are still many (sometimes several tens or even hundreds)
topic branch which do not contain it:

 a0--a1-----*a2-*a3-a4...-*a100
 |\         /   /         /
 | b0-B1..bN   /         /
 |\           /         /
 | c0..   ..cN         /
 \                    /
  z0..            ..zN

Here, the '*'s mark the first parent in merge, and uppercase B1 - the
commit where the line being blamed for was removed. Since commits cN-zN
do not contain B1, they still have the line removed in B1, and
reverse blame can report that the last commit for the line was zN
(meaning that it was removed in a100). In fact it really does return
some very late commit, and this makes it unusable for finding the B1
commit.

The search could be done by blame --reverse --first-parent. For range
a0..a100 it would return a1, and then only one additional blame along
the a0..bN will return the desired commit b0. But combining --reverse
and --first-parent was forbidden in 95a4fb0e, because incorrectly
specified range could produce unexpected and meaningless result.

Add test which describes the expected behavior of
`blame --reverse --first-parent` in the case described above.
Signed-off-by: NMax Kirillov <max@max630.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When prefixing a Git call in the test suite with 'debug ', it will
now be run with GDB, allowing the developer to debug test failures
more conveniently.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In ref-filter.c the comparison of refs while sorting is handled by
cmp_ref_sorting() function. When sorting as per numerical values
(e.g. --sort=objectsize) there is no fallback comparison when both
refs hold the same value. This can cause unexpected results (i.e. the
order of listing refs with equal values cannot be pre-determined) as
pointed out by Johannes Sixt ($gmane/280117).

Hence, fallback to alphabetical comparison based on the refname
whenever the other criterion is equal.

A test in t3203 was expecting that branch-two sorts before HEAD, which
happened to be how qsort(3) on Linux sorted the array, but (1) that
outcome was not even guaranteed, and (2) once we start breaking ties
with the refname, "HEAD" should sort before "branch-two" so the
original expectation was inconsistent with the criterion we now use.

Update it to match the new world order, which we can now depend on
being stable.
Helped-by: NJunio C Hamano <gitster@pobox.com>
Reported-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NKarthik Nayak <Karthik.188@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>