Re: Status of conflicted files resolved with rerere

From: Magnus Bäck <magnus.back@sonyericsson.com>
Date: Aug 15, 2010, 16:00 UTC
Message-ID: <20100815160022.GA31388@jpl.local>
In-Reply-To: <7veie0gy3r.fsf@alter.siamese.dyndns.org>

On Sunday, August 15, 2010 at 08:59 CEST,
     Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

> David Aguilar <davvid@gmail.com> writes:
> 
> > 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?"
> 
> I do not quite understand why the user _runs_ mergetool on a file that
> has been already merged; isn't it an option not to do so in the first
> place?

You have a point, but if there are conflicts in many files where only a subset were autoresolved I think it would be prudent to help the user. Grepping after remaining conflict markers or keeping the "git merge" output somewhere to see which files actually were autoresolved works but I think we can do better.

On the other hand, hinting mergetool users about rerere.autoupdate is perhaps good enough? Doesn't help users who want to inspect the autoresolved results yet also want hassle-free mergetool usage, though.

Show 9 quoted lines

> Having said that.
> 
> I think you can use the fact that:
> 
>  - "ls-files -u" will list paths with conflicts; and
> 
>  - "rerere status" won't mention the ones that have been autoresolved
> 
> if rerere is in effect (check for presense of .git/MERGE_RR).

Okay, I'll have a stab at a patch.

-- 
Magnus Bäck                      Opinions are my own and do not necessarily
SW Configuration Manager         represent the ones of my employer, etc.
Sony Ericsson