Re: Please pull ACPI updates

[Linus Torvalds]

On Thu, 17 Jul 2008, Len Brown wrote:
> 
> ps.
> 
> One thing I wish I had in git is a way to make this sequence easier...

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:

> Say I have a big topic branch with 30 patches in it.
> The 3rd patch turns out to have a bug in it, but the
> rest of the series is okay.  Today I invoke gitk on
> the branch and keep that open.
>
> Then I create a new topic branch at the broken patch.
> 
> I always consult ~/src/git/Documentation/git-reset.txt
> so I can remember the following sequence...
> 
> $ git reset --soft HEAD^
> $ edit
> $ git commit -a -c ORIG_HEAD
> 
> Now I've got the fixed 3rd patch checked in,
> but 27 patches in the original branch are hanging
> off the original broken 3rd patch.
> So I git-cherry-pick 27 patches
> I hope I get them in the right order and don't miss any...
> 
> It would be nice if we could somehow git rebase those
> 27 patches in a single command, but if we do,
> that pulls with it the broken 3rd patch.
> 
> come to think of it, I can probably export 4..27 as
> an mbox and then import it on top of the new 3,
> maybe that is what others do.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/