On Thu, 10 May 2007 09:01:15 -0700 (PDT), Linus Torvalds wrote: > Clearly git can, but equally clearly it really *would* be pretty nice if > you could just do > > git cherry-pick x y z > > and create one commit and have the message already somewhat done for you > (and "git revert" doing the same). Perhaps with a --squash option. I've already been wanting a cherry-pick that accepts a range, but that makes separate commits. Yes, I know there's some git-rebase thing that will do it, but I can never remember the right syntax for that without studying the documentation[*]. What I find myself wanting to type is just: git cherry-pick A..B But there is the whole problem of how to deal with any conflict that appears during the process. -Carl [*] I do use one form of rebase without ever needing to consult the documentation, but it's in the opposite "direction", if you will, from the cherry-pick-a-range operation. I use it when I want to rebase a set of commits from my current branch to some other branch, such as: git rebase origin Not surprisingly, what's common about both of the operations above is that they are really only accepting a single argument, (a range in one case, and a branch-name in the other). That's what makes for an easy-to-use command. Things that require multiple branch names in a particular order, or extra options, (see "git rebase --onto newbase upstream branch"), need someone smarter than me to drive them. Another problem is that using the optional final [<branch>] argument to git-rebase makes it change the current branch, (which no other git-rebase operation does), and that's another thing I find very confusing. I'm sure the most complex form of git-rebase solves some precise problem that someone has, (and maybe even gets used regularly). But it's got enough complications that I just ignore it, (and would instead really prefer being able to just cherry-pick a whole range).
Attachment:
pgpGcTxYZBJ3R.pgp
Description: PGP signature
