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

[Jakub Narebski <jnareb@gmail.com>]

Stephan Beyer wrote:
> Jakub Narebski wrote:

>>> Yes, you are right that am --rebasing is a no-op.
>>> That option was a little mystery to me, because it seemed to do nothing
>>> special, but I'll check again (bash-completion etc) and do appropriate
>>> changes.
>> 
>> Undocumented option '--rebasing' to git-am is internal option changing
>> git-am behavior to be better used by git-rebase, namely it does not
>> change commit message even if it doesn't follow git commit message
>> convention,
> 
> Ah yes, I've seen it now.
>
> 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.
 
> 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).

> The alternative for doing "pick" is teaching git-sequencer's "patch"
> insn an option that emulates the --rebasing behavior.
> 
> For me this feels somehow unclean. But perhaps there are good reasons.

Why unclean?

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.
 
> Of course, somehow I think that rebase and rebase-i should be merged,
> calling sequencer directly, with the main difference that -i will
> invoke an editor to allow editing of the TODO file.
> But nobody is hurt, if I put such a change far far away.

rebase-m and rebase-i can be merged; ordinary rebase uses other
mechanism: git-am pipeline, and not cherry-picking.

-- 
Jakub Narebski
Poland