Re: feature suggestion: improve rerere

[Johannes Sixt <j.sixt@viscovery.net>]

Am 3/6/2013 15:42, schrieb Uwe Kleine-König:
> On Wed, Mar 06, 2013 at 02:24:18PM +0100, Johannes Sixt wrote:
>> Am 3/6/2013 11:16, schrieb Uwe Kleine-König:
>>> 	++<<<<<<< ours
>>> 	 +ssize_t xread(int fd, void *buf, size_t count)
>>> 	 +{
>>> 	 +	ssize_t ret, done = 0;
>>> 	 +
>>> 	 +retry:
>>> 	 +	ret = read(fd, buf + done, count - done);
>>> 	 +	if (ret < 0)
>>> 	 +		return ret;
>>> 	 +
>>> 	 +	done += ret;
>>> 	 +
>>> 	 +	if (ret == 0 /* EOF */ || done == count)
>>> 	 +		return done;
>>> 	 +	else
>>> 	 +		goto retry;
>>> 	 +}
>>> 	 +
>>> 	++||||||| base
>>> 	++=======
>>> 	+ #include "common.h"
>>> 	+ 
>>> 	++>>>>>>> theirs
>>> 	  int main(int argc,char *argv[])
>>> 	  {
>>> 		int fd, val, ret, size, wrote, len;
>>>
>>> This is the same conflict as the first one, just with ours and theirs
>>> exchanged. So my suggestion is to make rerere use the resolution
>>> recorded for the first conflict here.
>>>
>>> Sounds sensible?
>>
>> Of course, and rerere already does it. But only when you use git's default
>> conflict markers rather than diff3 style markers that have this extra
>> ||||| line.
> I only did git checkout --conflict=diff3 after the merge conflict
> happend. So I cannot confirm that git already does it.
> 
> So here is a reproduction receipe:
> 
> 	git clone git://git.infradead.org/mtd-utils.git
> 	cd mtd-utils
> 	git checkout ca39eb1
> 	wget -O patch1 http://article.gmane.org/gmane.linux.drivers.mtd/45779/raw
> 	wget -O patch2 http://article.gmane.org/gmane.linux.drivers.mtd/45591/raw

At least patch2 has incorret index information; it does not apply with am
-3. I generated a working version with format-patch after applying it
directly on top of ca39eb1.

> 	for p in patch1 patch2; do perl -p -i -e 'print "From tralala Mon Sep 17 00:00:00 2001\n" if $. == 1' $p; done

Do you have rerere enabled at this point?

	git config rerere.enabled true

> 	git am patch1
> 	git am -3 patch2 # first merge conflict
> 	perl -n -i -e 's/=======//; print unless /^[<>]{7} /;' flash_otp_write.c # resolve
> 	git add flash_otp_write.c
> 	git am --resolved
> 	git rebase -i ca39eb1 # swap order of the two patches
> 
> results in
> 
> 	$ git ls-files -u
> 	100644 f360a3e025deaf7acfb7b20c9fad90f498ae4430 1	flash_otp_write.c
> 	100644 d407ebbf400e630dc00ee004ecb44be8af51b25d 2	flash_otp_write.c
> 	100644 31b963e2d6cf0016ca542529886e1ee71a22664e 3	flash_otp_write.c

Same here.

> 
> and resolving yields:
> 
> 	$ git ls-files -s flash_otp_write.c
> 	100644 648e0422d21c0ffa7621f82b86c02a065e488293 0	flash_otp_write.c

OK.

> 
> Then
> 	git rebase --continue 
> 
> gives the 2nd rebase conflict:
> 
> 	$ git ls-files -u
> 	100644 d407ebbf400e630dc00ee004ecb44be8af51b25d 1	flash_otp_write.c
> 	100644 648e0422d21c0ffa7621f82b86c02a065e488293 2	flash_otp_write.c
> 	100644 f360a3e025deaf7acfb7b20c9fad90f498ae4430 3	flash_otp_write.c

Same here.

> 
> Now knowing from the previous resolution that with base=f360a3e0
> (= origin + patch1) merging
> 
> 	d407ebbf (= origin) and
> 	31b963e2 (= origin + patch1 + patch2)
> 
> gives 648e0422 (origin + patch2),
> git could know that with base=d407ebbf (origin) merging 648e0422 (origin
> + patch1) and f360a3e0 (origin + patch1) gives 31b963e2 (origin + patch1
> + patch2) again.

For me, it works as expected, i.e., I get the conflict resolved by rerere.

> 
> And git doesn't prepare 31b963e2 in flash_otp_write.c for me.
> 
> @Johannes, do you have some non-standard setting, or can you reproduce?

Perhaps:

$ git config --global -l | grep rerere
rerere.enabled=true

-- Hannes