Re: Status of conflicted files resolved with rerere

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

 



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

> David Aguilar <davvid@xxxxxxxxx> 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.

> 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
--
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]