From: Chris Packham <judge.packham@gmail.com>
To: GIT <git@vger.kernel.org>
Subject: Redoing a merge for a particular file
Date: Fri, 8 Jul 2011 10:24:10 +1200 [thread overview]
Message-ID: <CAFOYHZCFetkokgtn4z0O3nPTEy6GCTEcN0Pzc8ce-joqMzZM1Q@mail.gmail.com> (raw)
Hi All,
I'm in the middle of merging to branches and I've screwed up my manual
merge, I've also got rerere enabled and I can't seem to get back into
a state to trigger git mergetool again.
$ git merge topic
...
$ git mergetool
$ make
error: foo.c ... oops screwed up that merge.
The merge wasn't too painful so I don't mind starting again.
$ git reset --hard HEAD^
HEAD is now at 59c6097 ...
$ git merge topic
Auto-merging foo.c
CONFLICT (content): Merge conflict in foo.c
Auto-merging bar.c
CONFLICT (content): bar.c
Auto-merging otherfile1.c
Auto-merging otherfile2.c
Auto-merging otherfile3.c
Resolved 'foo.c' using previous resolution.
Resolved 'bar.c' using previous resolution.
Automatic merge failed; fix conflicts and then commit the result.
$ git mergetool
No files need merging
So rerere has remembered the bad resolution of foo.c. But even if I
run 'git rerere clear' and repeat the above sequence I get the same
result. I seem to remember something like this coming up before.
Wasn't there an option added to checkout to allow us to recreate the
pre-merge state?
$ git checkout --merge foo.c
$ git mergetool
No files need merging
I can manually fix the error and amend the merge commit I just thought
git should be able to give me some help. I could have sworn that
checkout --merge is the right thing to do. Sure enough the man page
says it is "When checking out paths from the index, this option lets
you recreate the conflicted merge in the specified paths." maybe this
is a bug?
Looking at git status I think checkout is working as advertised but
maybe the bug is with mergetool.
$ git status
# On branch master
# Your branch is behind 'origin/master' by 1 commit, and can be
fast-forwarded.
#
# Changes to be committed:
....
# Unmerged paths:
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: foo.c
#
foo.c now does have conflict markers in it so I think it's crying out
to be re-merged I just can't convince mergetool to do it. Am I doing
something wrong?
Thanks,
Chris
P.S.
$ git --version
git version 1.7.5.4
next reply other threads:[~2011-07-07 22:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-07 22:24 Chris Packham [this message]
2011-07-07 22:41 ` Redoing a merge for a particular file Jeff King
2011-07-07 23:31 ` Chris Packham
2011-07-08 0:37 ` Junio C Hamano
2011-07-08 0:36 ` Junio C Hamano
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=CAFOYHZCFetkokgtn4z0O3nPTEy6GCTEcN0Pzc8ce-joqMzZM1Q@mail.gmail.com \
--to=judge.packham@gmail.com \
--cc=git@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).