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

Hi,

Jakub Narebski wrote:

quoted

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.

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).

Does someone have strong objections against that?

Speed could be one point in the case that git-apply just works without
needing threeway-fallback, but in the case of the fallback this will be
slower than pick, I think. So I'd not value that too high, but perhaps
there are opinions against my view.
Perhaps I am missing another point, too?


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.

for example if it begins not with single line summary
of commit, separated by empty line, but by multi-line paragraph.
See also t/t3405-rebase-malformed.sh

Well, I have a test script that runs
 for i in t0023* t3350* t340* t3901* t4014* t4150* t5520* t7402*
and I run that script before I do a commit and after I rebased.
And I ran the whole test suite before I posted the patchset to the list.
What I want to say is: t3405 did not fail with my --rebasing no-op.

That's perhaps one reason why I forgot about implementing --rebasing
correctly.

Although I am not sure if when rebase is rewritten using git-sequencer
implementing "git am --rebasing" would be truly needed.

I didn't want to touch that behavior for several reasons.

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.


Regards,
  Stephan

-- 
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F