From c8bae7493d2f2910b57f13ded012e86bdcfb0532 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 16:47:53 +0200 Subject: Adding upstream version 1:2.39.2. Signed-off-by: Daniel Baumann --- Documentation/RelNotes/1.7.10.3.txt | 43 +++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/RelNotes/1.7.10.3.txt (limited to 'Documentation/RelNotes/1.7.10.3.txt') diff --git a/Documentation/RelNotes/1.7.10.3.txt b/Documentation/RelNotes/1.7.10.3.txt new file mode 100644 index 0000000..703fbf1 --- /dev/null +++ b/Documentation/RelNotes/1.7.10.3.txt @@ -0,0 +1,43 @@ +Git v1.7.10.3 Release Notes +=========================== + +Fixes since v1.7.10.2 +--------------------- + + * The message file for German translation has been updated a bit. + + * Running "git checkout" on an unborn branch used to corrupt HEAD. + + * When checking out another commit from an already detached state, we + used to report all commits that are not reachable from any of the + refs as lossage, but some of them might be reachable from the new + HEAD, and there is no need to warn about them. + + * Some time ago, "git clone" lost the progress output for its + "checkout" phase; when run without any "--quiet" option, it should + give progress to the lengthy operation. + + * The directory path used in "git diff --no-index", when it recurses + down, was broken with a recent update after v1.7.10.1 release. + + * "log -z --pretty=tformat:..." did not terminate each record with + NUL. The fix is not entirely correct when the output also asks for + --patch and/or --stat, though. + + * The DWIM behaviour for "log --pretty=format:%gd -g" was somewhat + broken and gave undue precedence to configured log.date, causing + "git stash list" to show "stash@{time stamp string}". + + * "git status --porcelain" ignored "--branch" option by mistake. The + output for "git status --branch -z" was also incorrect and did not + terminate the record for the current branch name with NUL as asked. + + * When a submodule repository uses alternate object store mechanism, + some commands that were started from the superproject did not + notice it and failed with "No such object" errors. The subcommands + of "git submodule" command that recursed into the submodule in a + separate process were OK; only the ones that cheated and peeked + directly into the submodule's repository from the primary process + were affected. + +Also contains minor fixes and documentation updates. -- cgit v1.2.3