Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?

[Jakub Narebski <jnareb@gmail.com>]

Hi!

On Wed, 8 July 2008, Stephan Beyer wrote:
> Jakub Narebski wrote:
>> Stephan Beyer 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?

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?

Very good idea (I have proposed something similar either here on in
another thread).  It would avoid some unnecessary "marshalling" and
"unmarshalling" which is needed to transfer commit message [unchanged]
through git-format-patch -> git-am pipeline, namely putting first
paragraph into subject line, generating then parsing RFC-2822 date,
using quoted printable encoding for first paragraph / subject header
(I think).

It would be still better to fallback to _pick_, not "git am --3way",
as the latter IIRC use _shortened_ _blob_ identifiers for pre- and
post-image to find common ancestor (merge base) for 3way merge.
Which is not necessary as we can find merge base and base commits
easier.

-- 
Jakub Narebski
Poland