From: Junio C Hamano <gitster@pobox.com>
To: Martin Langhoff <martin.langhoff@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Should rerere auto-update a merge resolution?
Date: Fri, 25 Aug 2017 08:16:44 -0700 [thread overview]
Message-ID: <xmqqwp5ru17n.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CACPiFCJCgKtTbKX8jCSC3QgMKZ7Usu2ojqXe5w_QAHwk7T4M-A@mail.gmail.com> (Martin Langhoff's message of "Wed, 23 Aug 2017 17:12:04 -0400")
Martin Langhoff <martin.langhoff@gmail.com> writes:
> - when I tell it to forget, won't it forget the pre-resolution state?
I do not recall the details of what I did ;-) so I played around a
bit. Here is what I did:
git checkout master^0
git merge --no-ff --no-edit pb/trailers-from-command-line
git merge --no-ff --no-edit jk/trailers-parse
I know that the last one I know gets conflict and triggers rerere
to replay the recorded resolution. Imagine that I earlier botched
resolution and the working tree contents is wrong or something at
this point.
make test ;# fails, perhaps
So I can do:
git rerere forget <path>
After git rerere forget, I observe (check subdirectories in
.git/rr-cache/ whose timestamps are recent) that postimage gets
removed but preimage and thisimage stay.
I can then edit that file, and say "git rerere" again, which is
greeted by "Recorded resolution for '<path>'".
I do not recall if I designed it that way or not, but it even seems
to work correctly if you had "git add -u" after the botched auto
application (i.e. between the "make test" step and "rerere forget"
step in the above sequence). I never do "add -u" myself before
testing so I didn't notice.
If you want to _see_ the conflicts again while fixing a botched
resolution, then you'd need to do a bit more involved recovery.
After seeing "make test" fail and realize your older resolution is
botched, you'd probably do:
git checkout -m <path>
to unmerge, "rerere forget <path>", fix the botched resolution and
then finally "rerere" to record the correction.
next prev parent reply other threads:[~2017-08-25 15:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-23 19:39 Should rerere auto-update a merge resolution? Martin Langhoff
2017-08-23 20:34 ` Junio C Hamano
2017-08-23 21:12 ` Martin Langhoff
2017-08-25 10:19 ` Johannes Schindelin
2017-08-25 16:13 ` Junio C Hamano
2017-08-25 15:16 ` Junio C Hamano [this message]
2017-08-25 16:07 ` Junio C Hamano
2017-08-25 17:08 ` 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=xmqqwp5ru17n.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=martin.langhoff@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.