From: Jeff King <peff@peff.net>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH] rerere: fix for merge.conflictstyle
Date: Wed, 30 Apr 2014 02:08:35 -0400 [thread overview]
Message-ID: <20140430060835.GA21698@sigill.intra.peff.net> (raw)
In-Reply-To: <1398830909-24680-1-git-send-email-felipe.contreras@gmail.com>
On Tue, Apr 29, 2014 at 11:08:29PM -0500, Felipe Contreras wrote:
> If we use a different conflict style `git rerere forget` is not able to
> find the matching conflict SHA-1 because the diff generated is actually
> different from what `git merge` generated.
Can you show an example or test case?
I could not reproduce the problem with a trivial case, and rerere
specifically tries to handle the differences between "merge" and "diff3"
styles by throwing away the base content between "|" and "=" lines.
However, I wonder if it could still miss a match in some cases because
the "merge" style uses XDL_MERGE_ZEALOUS, whereas diff3 bumps it
down to XDL_MERGE_EAGER, which could lead to a slightly different
preimage.
If so, I think this points to a slightly more pervasive problem in
"rerere", then: data recorded under one merge level might not be usable
later (whether for "rerere forget" or for actually applying a
resolution).
The level can change if:
1. you have run something like "checkout --conflict=diff3" (and rerere
reads in the working tree file, which it does for regular
resolution, but not for "forget").
2. you use "git merge-file", which uses XDL_MERGE_ZEALOUS_ALNUM
3. you record resolutions and then change merge.conflictstyle
For (1), this is hopefully rarely going to be an issue, since "merge"
applies rerere itself before you get a chance to run checkout. So you
would have to manually run "git rerere" yourself (you might do that with
"rerere forget", but "forget" always re-runs the merge from the index).
For (2), we can hopefully ignore it, as merge-file does not run rerere
(and probably not many people use merge-file at all these days).
For (3), we can hopefully ignore this as rare; changing the variable
invalidates your cache, but only the hunks for which the ZEALOUS/EAGER
level makes a difference.
There isn't currently a way to tweak the merge-level manually, which
would be the other obvious way to trigger the situation.
We already get around the merge/diff3 format by trying to normalize the
merge/diff3 hunks we see. It would be nice if we could normalize away
the merge-levels, too, but I don't think that is possible just from the
conflict data. We'd have to actually re-run the low-level merge with
known settings. For git-merge, that would mean doubling the work when
"rerere" is in use. And it would mean that we could not run "rerere" on
a partially-resolved file.
So given all of the "hopefully rare" statements above and the complexity
of the complete solution, it's probably not worth pursuing. In which
case your patch seems like the best we can do. At least it covers the
more common case when you have set merge.conflictstyle but _didn't_
change it since the postimage was recorded.
-Peff
next prev parent reply other threads:[~2014-04-30 6:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 4:08 [PATCH] rerere: fix for merge.conflictstyle Felipe Contreras
2014-04-30 6:08 ` Jeff King [this message]
2014-04-30 6:49 ` Felipe Contreras
2014-04-30 14:04 ` 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=20140430060835.GA21698@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@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 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).