Re: [PATCH 2/2] mergetool: fix running mergetool in sub-directories

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 1, 2009, 01:32 UTC
Message-ID: <7v63jv0wn6.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1233357611-31820-2-git-send-email-charles@hashpling.org>

Charles Bailey <charles@hashpling.org> writes:

Show 20 quoted lines

> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index aefdca7..87fa88a 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -13,7 +13,6 @@ SUBDIRECTORY_OK=Yes
>  OPTIONS_SPEC=
>  . git-sh-setup
>  require_work_tree
> -prefix=$(git rev-parse --show-prefix)
>  
>  # Returns true if the mode reflects a symlink
>  is_symlink () {
> @@ -131,7 +130,7 @@ checkout_staged_file () {
>      tmpfile=$(expr "$(git checkout-index --temp --stage="$1" "$2")" : '\([^	]*\)	')
>  
>      if test $? -eq 0 -a -n "$tmpfile" ; then
> -	mv -- "$tmpfile" "$3"
> +	mv -- "$(git rev-parse --show-cdup)$tmpfile" "$3"
>      fi
>  }

Looking at the above change together with this disabled patch in the previous,

Show 11 quoted lines

> +# We can't merge files from parent directories when running mergetool
> +# from a subdir. Is this a bug?
> +#
> +#test_expect_failure 'mergetool in subdir' '
> +#    cd subdir && (
> +#    ( yes "" | git mergetool ../file1 >/dev/null 2>&1 ) &&
> +#    ( yes "" | git mergetool ../file2 >/dev/null 2>&1 ) &&
> +#    test "$(cat ../file1)" = "master updated" &&
> +#    test "$(cat ../file2)" = "master new" &&
> +#    git commit -m "branch1 resolved with mergetool - subdir" )
> +#'

I wonder if it would be cleaner to keep $prefix and instead cd_to_toplevel at the beginning.

There are two ways for Porcelain scripts to work from inside a subdirectory of a project.

 * Stay in the original subdirectory and use show-cdup to convert a path
   that is relative to the repository root to a path relative to your
   current subdirectory.

 * Go up to the root of the work tree, use prefix to convert a path that
   is relative to the original subdirectory to a path relative to the root
   of the work tree.

The former way is probably the clunkier one between the two. I think the latter is how most of the Porcelain scripts work when they need to worry about the Plumbing commands that return/accept repository relative paths. Also, all the plumbing commands work in the latter way.