Stephan Beyer wrote: > 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. 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. > 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 -- 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
