CasperSecurity
Git 2.25.2 Release Notes
========================
Fixes since v2.25.1
-------------------
* Minor bugfixes to "git add -i" that has recently been rewritten in C.
* An earlier update to show the location of working tree in the error
message did not consider the possibility that a git command may be
run in a bare repository, which has been corrected.
* The "--recurse-submodules" option of various subcommands did not
work well when run in an alternate worktree, which has been
corrected.
* Running "git rm" on a submodule failed unnecessarily when
.gitmodules is only cache-dirty, which has been corrected.
* "git rebase -i" identifies existing commits in its todo file with
their abbreviated object name, which could become ambigous as it
goes to create new commits, and has a mechanism to avoid ambiguity
in the main part of its execution. A few other cases however were
not covered by the protection against ambiguity, which has been
corrected.
* The index-pack code now diagnoses a bad input packstream that
records the same object twice when it is used as delta base; the
code used to declare a software bug when encountering such an
input, but it is an input error.
* The code to automatically shrink the fan-out in the notes tree had
an off-by-one bug, which has been killed.
* "git check-ignore" did not work when the given path is explicitly
marked as not ignored with a negative entry in the .gitignore file.
* The merge-recursive machinery failed to refresh the cache entry for
a merge result in a couple of places, resulting in an unnecessary
merge failure, which has been fixed.
* Fix for a bug revealed by a recent change to make the protocol v2
the default.
* "git merge signed-tag" while lacking the public key started to say
"No signature", which was utterly wrong. This regression has been
reverted.
* MinGW's poll() emulation has been improved.
* "git show" and others gave an object name in raw format in its
error output, which has been corrected to give it in hex.
* Both "git ls-remote -h" and "git grep -h" give short usage help,
like any other Git subcommand, but it is not unreasonable to expect
that the former would behave the same as "git ls-remote --head"
(there is no other sensible behaviour for the latter). The
documentation has been updated in an attempt to clarify this.
Also contains various documentation updates, code clean-ups and minor fixups.