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

From: Richard Hansen <hansenr@google.com>
Date: Jan 7, 2017, 02:16 UTC
Message-ID: <7a561587-3afc-58f9-a490-6bcaa7287576@google.com>
In-Reply-To: <199807ae-844c-57cd-28cf-2c10b3aee7a9@kdbg.org>

On 2017-01-06 04:42, Johannes Sixt wrote:

Show 33 quoted lines

> 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@google.com>
>> ---
>>  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 -- "$@"`?

The arguments passed to 'git diff' (including the -O argument) are all interpreted as relative to the current working directory, yet 'git diff --name-only' outputs pathnames that are relative to the top-level directory. Thus:

   * cd_to_toplevel MUST NOT be run before that 'git diff' command
     unless all pathnames relative to $PWD are converted to absolute (or
     relative to the top-level directory), and
   * cd_to_toplevel MUST be run after 'git diff' so that $files is
     interpreted correctly.

And now I realize that my change breaks -O<foo> if <foo> is relative to $PWD. Grr. Too bad we don't have tests for running mergetool -O<relative-path> from a subdirectory.

Show 5 quoted lines

>
> 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.

Reverting to the previous control flow won't work unless the -O pathname is converted to absolute (or relative to the top-level directory). But I'll have to do that anyway. Blech.

Do we already have a helper shell function somewhere that converts a pathname to absolute? Thanks to symlinks it's trickier than one might expect.

Thanks, Richard

>
> -- Hannes