From: Stephan Beyer <s-beyer@gmx.net>
Date: Tue, 08 Jul 2008 16:34:30 GMT
Subject: Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
Message-ID: <20080708163430.GK6726@leksak.fem-net>
In-Reply-To: <200807081812.15651.jnareb@gmail.com>

Hi,

Jakub Narebski wrote:
> > It is taking the commit message from the commit in the "From <commit> .*"
> > line, does *not* change it in any way and then applies the changes using
> > threeway merge.
> 
> Not exactly.  "git am --rebasing" still tries to first just *apply*
> the patch, then (I think) it falls back on blob-id based 3way merge.

That's of course totaly right and what I've meant, but unfortunately not
what I've written ;-)

> > Keeping that in mind what about dealing with --rebasing like that:
> > if --rebasing is given, git am simply generates
> > 	pick <commit>
> > lines, instead of
> > 	patch -3 -k <msg>
> > as it is now (and this is not enough, as it seems).
> 
> It is not.
> 
> Nevertheless it would be I think better for ordinary patch based rebase
> to fall back not on git-am 3way merge, but on cherry-pick based merge
> (i.e. on pick).

Hmm, if I get you right you _partly_ agree with me in choosing "pick" for
am --rebasing... But cherry-pick should only be chosen if a simple git-apply
failed first. Right?

I just got another idea which could easily be done and perhaps is the
right thing :)
Generating
	patch -C <commit> -3 <file>

This takes authorship and message from <commit> and does the usual
threeway-fallback behavior.

What do you think?

> But I agree that it would be nice to simplify '--rebasing' logic, for
> example using patch or 2way merge to generate tree, and commit message
> taken directly from commit, not via 'format-patch | am' pipeline.

That's right, but that would require me to hack around in git-rebase
which I tried to avoid for now. :)

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F