Eric Wong <normalperson@xxxxxxxx> writes: > Junio C Hamano <junkio@xxxxxxx> wrote: >> >> >> git-merge-$strategy $cmt^ -- HEAD $cmt >> > >> > Changing the 'git-merge $strategy_args "rebase-merge: $cmt" HEAD "$cmt"' >> > line in call_merge() to this seems to have broken more tests. >> >> Oh, that is to be expected if you changed git-merge -s recursive >> with git-merge-recursive without other changes. The former >> makes a commit (which your original patch later used to create a >> separate commit chain and discarded); the latter does not make a >> commit but expects the caller to create a commit out of the >> resulting index file. > > Oops, *smacks head* Well, but you used it to do the right thing after all ;-). The patch looks quite good. >> I was originally hoping that rebasing would just be a matter of >> listing sequence of commits to be ported onto a new base and >> running "git-cherry-pick" on each of them in sequence. Now >> cherry-pick does not use merge machinery (hence does not use >> git-merge-recursive), but if we change that then updating rebase >> would be pretty much straightforward. It just needs a UI layer >> to guide the user through recovery process when the merge does >> not resolve cleanly in the middle, no? > > Sounds workable right to me. But then again, a cherry-pick is also a > case of rebase on a single commit, so we could be using rebase (and its > recovery code) in cherry-pick, too, right? Revert and cherry-pick are quite similar operation (the only difference is that you swap his and pivot when doing revert), so when you implement cherry-pick as an atomic operation you can have revert almost for free. If you have a rebase like you did, it would be a bit more involved to make it do revert as well. - : 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