Re: feature suggestion: improve rerere

From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Mar 6, 2013, 14:42 UTC
Message-ID: <20130306144225.GB15375@pengutronix.de>
In-Reply-To: <51374382.6050101@viscovery.net>

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

Show 37 quoted lines

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

and resolving yields:

	$ git ls-files -s flash_otp_write.c
	100644 648e0422d21c0ffa7621f82b86c02a065e488293 0	flash_otp_write.c

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

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.

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?

Best regards Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |