Hi, Jakub Narebski wrote: > > 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. That's of course totaly right and what I've meant, but unfortunately not what I've written ;-) > > 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). Hmm, if I get you right you _partly_ agree with me in choosing "pick" for am --rebasing... But cherry-pick should only be chosen if a simple git-apply failed first. Right? I just got another idea which could easily be done and perhaps is the right thing :) Generating patch -C <commit> -3 <file> This takes authorship and message from <commit> and does the usual threeway-fallback behavior. What do you think? > 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. That's right, but that would require me to hack around in git-rebase which I tried to avoid for now. :) 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
