Re: Status of conflicted files resolved with rerere

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Aug 12, 2010, at 2:36 PM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote:

On Thu, Aug 12, 2010 at 5:28 PM, Magnus Bäck
<magnus.back@xxxxxxxxxxxxxxxx> wrote:
I played around with git rerere today and was surprised by the results.
When a conflict has been resolved automatically by rerere, the file
isn't added to the index like other files are where Git just used one of the regular merge resolution algorithms. What's worse, if git mergetool is invoked -- which is what I normally do when git merge needs help --
it has no idea that the file actually has been merged already, and
launches the merge tool with the three files involved in the merge. If
the user hasn't been paying attention to each line of the git merge
output (stating the files who were automatically resolved) it's easy to
trash rerere's work.
[...]
It sounds like the real problem here though it the mergetool stuff.
Why is it disregarding all the automated merging that git has done and
starting over from scratch?  If git, in its infinite cleverness, has
resolved *some* parts of the file but not others, wouldn't we want it
to keep those resolutions?  It sounds like mergetool is actually
making things *more* work instead of less.

Is there some way to teach the mergetool stuff to be smarter?  At the
very least, having it auto-skip files that have no *remaining*
conflicts might be a good idea.

Have fun,

Avery

Right, that would be a great enhancement.

The problem is that mergetool always uses local, remote, and base. It uses the unmerged flag in the index when deciding which files to consider.

Here's what we'd need in order to improve rerere and mergetool interaction: the ability to answer the question, "has this file been rerere merged?"

Once we have that then we can make mergetool skip these files by default. We would also need a command line flag to override the behaviour.

Perhaps a naive grep for merge markers in the worktree file would suffice? Heuristics have gone a long way in git so doing something like that wouldn't seem too atrocious.

It'd also have the benefit that mergetool would skip files merged by $EDITOR.

If anyone has any tips I'm all ears. Does this seem reasonable, and if so, what would be a good name for the command line flag to get the existing behavior? My gut feeling is that it shouldn't have a corresponding config variable.

Cheers,
--
        David--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]