2.25.2

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.