On Fri, 12 Mar 2010, Chris Packham wrote: > On Thu, Mar 11, 2010 at 3:20 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > 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. Note that "git checkout --merge <file>" re-creates <file> in the state of textual merge conflict from the index (from stages 1, 2, 3). It is not able, unfortunately, to recover stages in index if you marked <file> as resolved using "git add <file>". Note also that you would get non-0 stages in index only if there was a *merge conflict* for a file which was not automatically resolved. If cpu/mpc83xx/start.S resolved cleanly, it would be in stage-0 only. You can check what stages you have in index for a specified file using $ git ls-files --stage cpu/mpc83xx/start.S If you don't have stages 1 and 2 in the index (which you can check using command provided above), you can instead get versions of a file which would be used in resolving conflict: $ git show HEAD:cpu/mpc83xx/start.S \ >cpu/mpc83xx/start.S.ours $ git show MERGE_HEAD:cpu/mpc83xx/start.S \ >cpu/mpc83xx/start.S.theirs $ git show $(git merge-base HEAD MERGE_HEAD):cpu/mpc83xx/start.S \ >cpu/mpc83xx/start.S.base Sidenote: versions in stage 1, 2, 3 differ from above versions in that they have those conflict (chunks) that can be automatically resolved, resolved. HTH -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html