From: Jakub Narebski <jnareb@gmail.com>
To: Chris Packham <judge.packham@gmail.com>
Cc: GIT <git@vger.kernel.org>
Subject: Re: re-running merge on a single file
Date: Fri, 12 Mar 2010 10:00:23 +0100 [thread overview]
Message-ID: <201003121000.25217.jnareb@gmail.com> (raw)
In-Reply-To: <a038bef51003111633v5d5d418bu332b63bb3874e3ef@mail.gmail.com>
On Fri, 12 Mar 2010, Chris Packham wrote:
> On Thu, Mar 11, 2010 at 3:20 PM, Jakub Narebski <jnareb@gmail.com> 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
prev parent reply other threads:[~2010-03-12 9:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-11 18:54 re-running merge on a single file Chris Packham
2010-03-11 19:09 ` Chris Packham
2010-03-11 20:29 ` Markus Heidelberg
2010-03-11 22:08 ` Chris Packham
2010-03-11 23:20 ` Jakub Narebski
[not found] ` <a038bef51003111631n38f7e50cp79d8335109f3ed0@mail.gmail.com>
2010-03-12 0:33 ` Chris Packham
2010-03-12 6:45 ` Johannes Sixt
2010-03-12 6:56 ` Junio C Hamano
2010-03-12 20:16 ` Chris Packham
2010-03-12 21:16 ` Chris Packham
2010-03-12 23:07 ` Junio C Hamano
2010-03-12 23:43 ` Chris Packham
2010-03-14 12:24 ` Kris Shannon
2010-03-12 9:00 ` Jakub Narebski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201003121000.25217.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=judge.packham@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.