Linus Torvalds <torvalds@xxxxxxxx> writes: > Personally, I think the rebase syntax sucks, because the _natural_ way > to do it is to just describe the set of commits to rebase the same way > we describe all _other_ commit sets: as a "begin..end" sequence. I'd agree in general, and I am not happy about them. But I have an excuse. rev-parse's A..B notation was invented on June 13th (178cb24). But format-patch was originally posted on May 30th: http://article.gmane.org/gmane.comp.version-control.git/4279 before the convenience of rev-parse was invented ;-). > So I think rebase _should_ work something like this: > > git rebase origin.. [--onto] linus > > ie just giving an arbitrary range. In addition, both rebase and format-patch does a bit more than straight his..mine. *---x---x---o---o---o---o \ ^mine .---.---.---. ^his We do _not_ want to process all six of his..mine commits when doing "format-patch his mine" in the above picture, because upstream might have accepted some of them already, and we filter them out with git-cherry. > This is even more noticeable for "git-format-patch", where > that insane "<his> [<mine>]" syntax is even worse, for no > good reason, when again it should really just work like "git > diff" where giving a single revision implies a single > revision, and giving a range implies a range, and no strange > "mine" vs "his" rules ] Having said that, you have been able to say format-patch A..B C..D E..F for quite some time (since November 21, 2005). Rebase is even more strange, especially with --onto. When you do $ rebase --onto his origin mine in this picture, *---x---x---o---o---o---o \ ^origin ^mine .---.---.---. ^his you are discarding two 'x' commits, and lost-found is the only thing that would help you to recover them. Unlike format-patch which takes ranges, rebase does not let you say "rebase --onto base A..B C..D E..F"; what happens might be too confusing, especially if B, D, F are not coming from the current branch. The current branch is rewound to base and then the chosen sets of patches are applied, which is kind-of scary. It would feel safer to do: $ git checkout -b newbranch base $ git format-patch --stdout A..B C..D E..F | git am -3 and after making sure the result is really what you want resetting the original branch to the current (newbranch) head. - : 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