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
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/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
