Re: feature suggestion: improve rerere

Am 3/6/2013 15:42, schrieb Uwe Kleine-König:

On Wed, Mar 06, 2013 at 02:24:18PM +0100, Johannes Sixt wrote:

quoted

Am 3/6/2013 11:16, schrieb Uwe Kleine-König:

quoted

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