re-running merge on a single file

> Alternatively I could manually drive and external merge tool like
> kdiff3 if I had a recipe for getting the common ancestor revision.
> Something like
>
> git checkout <magic pathspec> -- file
> mv file file.base

> In other cases I'm actually thinking
> that it'd be easier to ask git to try the merge again on that one
> file. I can ask git difftool to show me the pre-merge differences with
> 'git difftool master..vendor <file>' but what I'd really like to do is
> ask git mergetool to do something similar so I can re-do my manual
> merging.

> Alternatively I could manually drive and external merge tool like
> kdiff3 if I had a recipe for getting the common ancestor revision.
> Something like
> 
> git checkout <magic pathspec> -- file
> mv file file.base

> Hmm, having trouble with cat-file syntax
> 
> On Thu, Mar 11, 2010 at 12:29 PM, Markus Heidelberg
> <markus.heidelberg@web.de> wrote:
> > Not mergetool, but checkout:
> > git checkout --merge -- file
> 
> Ok.
> $ git checkout --merge -- cpu/mpc83xx/start.S
> 
> > git cat-file blob :1:file > file.base
> >
> 
> $ git cat-file blob :1:cpu/mpc83xx/start.S > cpu/mpc83xx/start.S.base
> fatal: Not a valid object name :1:cpu/mpc83xx/start.S
> 
> So I think I have figured out that I'm trying to get at stage 1, 2 and
> 3 of the file that git checkout --merge has just setup but I'm
> tripping over the syntax.

>
> First, instead of 'git cat-file blob <blob-id>' you can simply use
> 'git show <blob-id>'.
>
> Second, while in
>
>  $ git checkout --merge -- cpu/mpc83xx/start.S
>
> the path cpu/mpc83xx/start.S is relative to your current directory,
> in
>
>  $ git show :1:cpu/mpc83xx/start.S > start.S.base
>
> the path has to be "absolute path in repository", i.e. path relative
> to top directory of the repository.

>
> Try
>
>  $ git show :1:$(git rev-parse --show-prefix)cpu/mpc83xx/start.S \
>    > cpu/mpc83xx/start.S.base

> Chris Packham schrieb:
>> $ git checkout --merge -- cpu/mpc83xx/start.S
>> $ git show :1:$(git rev-parse --show-prefix)cpu/mpc83xx/start.S
>> fatal: Path 'cpu/mpc83xx/start.S' is in the index, but not at stage 1.
>> Did you mean ':0:cpu/mpc83xx/start.S'?
>
> Both of these work only as long as the index still records the conflicted
> state. If you (or one of your tools) has git-added the file, or you have
> git-checked-out some version of the file, the conflict stages are lost,
> and you must reset --hard and redo the entire merge.

> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Chris Packham schrieb:
>>> $ git checkout --merge -- cpu/mpc83xx/start.S
>>> $ git show :1:$(git rev-parse --show-prefix)cpu/mpc83xx/start.S
>>> fatal: Path 'cpu/mpc83xx/start.S' is in the index, but not at stage 1.
>>> Did you mean ':0:cpu/mpc83xx/start.S'?
>>
>> Both of these work only as long as the index still records the conflicted
>> state. If you (or one of your tools) has git-added the file, or you have
>> git-checked-out some version of the file, the conflict stages are lost,
>> and you must reset --hard and redo the entire merge.
>
> If the merge textually autoresolves cleanly, you might not even have any
> conflicted state to begin with.  In such a case you would need to grab
>
>        MERGE_HEAD:path-to-that-thing
>        HEAD:path-to-that-thing
>
> yourself.
>

> On Thu, Mar 11, 2010 at 10:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>
>>> Chris Packham schrieb:
>>>> $ git checkout --merge -- cpu/mpc83xx/start.S
>>>> $ git show :1:$(git rev-parse --show-prefix)cpu/mpc83xx/start.S
>>>> fatal: Path 'cpu/mpc83xx/start.S' is in the index, but not at stage 1.
>>>> Did you mean ':0:cpu/mpc83xx/start.S'?
>>>
>>> Both of these work only as long as the index still records the conflicted
>>> state. If you (or one of your tools) has git-added the file, or you have
>>> git-checked-out some version of the file, the conflict stages are lost,
>>> and you must reset --hard and redo the entire merge.
>>
>> If the merge textually autoresolves cleanly, you might not even have any
>> conflicted state to begin with.  In such a case you would need to grab
>>
>>        MERGE_HEAD:path-to-that-thing
>>        HEAD:path-to-that-thing
>>
>> yourself.
>>
>
> So if I understand correctly once I've committed the merge the various
> stages and MERGE_HEADs go away. I don't really want to re-do the whole
> merge which is probably the correct thing to do. I'm lazy and my
> projects rules allow broken commits so instead I can poke about with
> git show and various revisions.
>
> Here's a simple script that does just that. I've borrowed some command
> line options from git mergetool (Warning: gmail web interface). If
> anyone is interested in seeing a proper version of this I can clean it
> up submit it properly.
>
> ----8<----
>
> From c6ad177712422cbba641975d9e6a5fe85fc8f1fa Mon Sep 17 00:00:00 2001
> From: Chris Packham <judge.packham@gmail.com>
> Date: Fri, 12 Mar 2010 12:03:02 -0800
> Subject: [PATCH] Add git manual-merge command
>
> Can be used to manually merge files from the specified revisions.
> ---
>  git-manual-merge |   91 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 91 insertions(+), 0 deletions(-)
>  create mode 100755 git-manual-merge
>
> diff --git a/git-manual-merge b/git-manual-merge
> new file mode 100755
> index 0000000..f37ba88
> --- /dev/null
> +++ b/git-manual-merge
> @@ -0,0 +1,91 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2010 Chris Packham
> +#
> +# Based on git-mergetool by Theodore Y. Ts'o
> +#
> +# This file is licensed under the GPL v2
> +#
> +
> +USAGE='<branch1> <branch2> <file> ...'
> +. git-sh-setup
> +. git-mergetool--lib
> +require_work_tree
> +
> +merge_one_file()
> +{
> +    local has_base=false
> +    git show $1:$4 > $4.$1 && has_base=true
> +    git show $2:$4 > $4.$2 || die
> +    git show $3:$4 > $4.$3 || die
> +
> +    if "$prompt" = true; then
> +       printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
> +       read ans
> +    fi
> +
> +    if "$has_base" = true; then
> +        $merge_tool $4.$1 $4.$2 $4.$1 -o $4

> +    else
> +        $merge_tool $4.$2 $4.$1 -o $4
> +    fi
> +}
> +
> +prompt=$(git config --bool mergetool.prompt || echo true)
> +
> +while test $# != 0
> +do
> +    case "$1" in
> +        -t|--tool*)
> +            case "$#,$1" in
> +                *,*=*)
> +                    merge_tool=$(expr "z$1" : 'z-[^=]*=\(.*\)')
> +                    ;;
> +                1,*)
> +                    usage ;;
> +                *)
> +                    merge_tool="$2"
> +                    shift ;;
> +            esac
> +            ;;
> +        -y|--no-prompt)
> +            prompt=false
> +            ;;
> +        --prompt)
> +            prompt=true
> +            ;;
> +        --)
> +            shift
> +            break
> +            ;;
> +        -*)
> +            usage
> +            ;;
> +        *)
> +            break
> +            ;;
> +    esac
> +    shift
> +done
> +
> +echo "$merge_tool"
> +
> +if test $# -lt 3; then
> +    usage
> +fi
> +
> +branch1=$(git rev-parse --short  $1)
> +branch2=$(git rev-parse --short  $2)
> +_base=$(git merge-base $branch1 $branch2)
> +base=$(git rev-parse --short  $_base)
> +
> +if test -z "$merge_tool"; then
> +    merge_tool=$(get_merge_tool "$merge_tool") || exit
> +fi
> +
> +shift 2
> +
> +for x in $*; do
> +    merge_one_file $base $branch1 $branch2 $x
> +done
> +
> --
> 1.7.0.1
>

> Chris Packham <judge.packham@gmail.com> writes:
>
>> ... I'm lazy and my
>> projects rules allow broken commits so ...
>
> We cannot fix, nor it is our job to fix, lazy people or undisciplined
> projects ;-)

> Having said that you can still retry your merge, which was _mostly_ Ok.
>
>  (1) First, check out the original commit before the merge.  You may have
>     built a few more commits on top of it, so "git log --first-parent"
>     may help to find that commit.  Suppose you found that merge commit
>     and we call that $merge; then:
>
>     $ git checkout $merge^1
>
>  (2) Then you retry that merge:
>
>     $ git merge $merge^2
>
>     which would conflict the same way you saw.
>
>  (3) If you have rerere enabled, then the conflicts would be already
>     resolved in your working tree at this point, but not in the index, so
>     you can reproduce the conflicted state with "checkout -m".

>  (4) If you didn't have rerere enabled, then you would have a lot of
>     conflicted files in the working tree.  Inspect them by comparing with
>     $merge:
>
>     $ git diff $merge
>
>     Since we are assuming that most of the resolution was good, and you
>     know what paths you want to fix your earlier resolution for, you
>     would want to take what is in $merge for most of the paths.  You can
>     run checkout on paths that you know were good in $merge, like so:
>
>     $ git checkout $merge -- include/ drivers/
>
>     and repeat this step to narrow it down to the paths you are
>     interested in.
>
>  (5) After you fix the resolution and make a commit,
>
>     $ git diff $merge
>
>     will show that your earlier incorrect resolution is replaced by a new
>     correct resolution.
>
> After that, you can rebase your branch on top of HEAD to conclude.
>
> Note that recent git can use "checkout -m path" to reproduce conflicts
> even after you ran "git add path".

> On Fri, Mar 12, 2010 at 3:07 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>  (3) If you have rerere enabled, then the conflicts would be already
>>     resolved in your working tree at this point, but not in the index, so
>>     you can reproduce the conflicted state with "checkout -m".
>
> Mental note: Need to learn more about git rerere. Sounds like what I
> need to do the job.
>

> > Try
> >
> >  $ git show :1:$(git rev-parse --show-prefix)cpu/mpc83xx/start.S \
> >    > cpu/mpc83xx/start.S.base
> 
> git show doesn't complain about the path. But I'm obviously not
> setting the stage correctly
> 
> $ git checkout --merge -- cpu/mpc83xx/start.S
> $ git show :1:$(git rev-parse --show-prefix)cpu/mpc83xx/start.S
> fatal: Path 'cpu/mpc83xx/start.S' is in the index, but not at stage 1.
> Did you mean ':0:cpu/mpc83xx/start.S'?
> 
> By now I have additional commits that touch cpu/mpc83xx/start.S so
> I'll see if I can find a file that I haven't touched since the merge.