Filename: /////usr/share//doc/git//RelNotes/2.25.2.txt

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.

./Ninja\.