Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Jul 8, 2008, 16:12 UTC
- Message-ID
- <200807081812.15651.jnareb@gmail.com>
- In-Reply-To
- <20080708144239.GJ6726@leksak.fem-net>
Stephan Beyer wrote:
> Jakub Narebski wrote:
Show 15 quoted lines
>>> 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.
Show 6 quoted lines
> 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