Hi,

Jakub Narebski wrote:
quoted text
> > 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.

quoted text
> 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.

quoted text
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html