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

From: Stephan Beyer <s-beyer@gmx.net>
Date: Jul 8, 2008, 14:42 UTC
Message-ID: <20080708144239.GJ6726@leksak.fem-net>
In-Reply-To: <200807080939.31216.jnareb@gmail.com>

Hi,

Jakub Narebski wrote:

Show 9 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.

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 <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F