Re: [PATCH v2 4/4] mergetool: fix running in subdir when rerere enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 06.01.2017 um 02:09 schrieb Richard Hansen:
If rerere is enabled and no pathnames are given, run cd_to_toplevel
before running 'git diff --name-only' so that 'git diff --name-only'
sees the pathnames emitted by 'git rerere remaining'.

Also run cd_to_toplevel before running 'git rerere remaining' in case
'git rerere remaining' is ever changed to print pathnames relative to
the current directory rather than to $GIT_WORK_TREE.

This fixes a regression introduced in
57937f70a09c12ef484c290865dac4066d207c9c (v2.11.0).

Signed-off-by: Richard Hansen <hansenr@xxxxxxxxxx>
---
 git-mergetool.sh     | 1 +
 t/t7610-mergetool.sh | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/git-mergetool.sh b/git-mergetool.sh
index e52b4e4f2..67ea0d6db 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -456,6 +456,7 @@ main () {

 	if test $# -eq 0 && test -e "$GIT_DIR/MERGE_RR"
 	then
+		cd_to_toplevel
 		set -- $(git rerere remaining)
 		if test $# -eq 0
 		then

This cannot be a complete solution. Why do we have another cd_to_toplevel later, after `git diff --name-only -- "$@"`?

Maybe it is necessary to revert back to the flow control that we had before 57937f70a09c ("mergetool: honor diff.orderFile", 2016-10-07)? It did not have `test $# -eq 0` and `test -e "$GIT_DIR/MERGE_RR"` in a single condition.

-- Hannes




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]