Actually, it _is_ easier, although apparently the thing that made it
easier isn't necessarily widely known or documented.
I'm going to quote your whole sequence, because it's not a really odd
thing do want to do, and quoting how you do it now also makes the "proper
git way" actually much more understandable:
No, what others do (if they know the tricks) is to say something like:
git rebase -i <starting-point>
("-i" is short for "--interactive") where the starting point is just where
you want to start your work. It might be "origin", or it might be
"HEAD~30" to say "30 commits ago" or whatever. Anyway, it's basically the
stable point before the place you want to fix up.
That thing will literally show you the list of commits in an editor, and
then you can re-order them or mark them for special actions.
The normal action is to "pick" the commit (ie you just cherry-pick it).
But rather than just picking a commit (remember - you can change the order
by just editing the list), you can also do
- "edit": this just basically pauses the rebase after committing the
cherry-pick, so that you can then edit things and fix them with "git
commit --amend", and when you're happy, you do "git rebase --continue"
to continue your series.
- "squash": this squashes the commit in togethr with the previous one,
and is very useful together with moving commits around. IOW, maybe you
committed a fix to a previous commit, and want to integrate the fix
into the original commit - in that case you'd move the commit in the
list up to just after the commit you want to fix, and change the "pick"
into a "squash"
so it actually makes doing what you do above by hand much easier.
[ Honesty in advertising: I actually don't use this at all. I've tested
it, and I think it's very useful, but I have so far mostly ended up
doing this by hand in the very few cases I do it at all. Part of the
reason is that "git rebase -i" is fairly recent, so it's not part of my
normal tool set.
But the bigger reason is that obviously all the commits I tend to do are
just merges, and I don't maintain "patch series" in my trees except
sometimes for git itself ]
Git rebase can also try to rebase merges (the "-p" flag - short form of
"--preserve-merges"), so this _does_ work with a non-linear history too to
some degree, but quite frankly, I would seriously suggest people try to
avoid getting quite that funky with it. It's useful for emergencies, but
you'd better know what you are doing, and you should look at the
before-and-after state very carefully.
Linus
--
