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