Re: git pull on Linux/ACPI release tree

[Linus Torvalds]

On Mon, 9 Jan 2006, Martin Langhoff wrote:
> 
> I think it does. All the tricky stuff that David and Junio have been
> discussing is actually done very transparently by
> 
>     git-rebase <upstream>

Yes, it's fairly easy to do. That said, I would actually discourage it. I 
haven't said anything to David, because he is obviously very comfy with 
the git usage, and it _does_ result in cleaner trees, so especially since 
the networking code ends up being the source of a lot of changes, the 
extra cleanup stage that David does might actually be worth it for that 
case.

But git is actually designed to have parallel development, and what David 
does is to basically artificially linearize it. We merge between us often 
enough that it doesn't really end up losing any historical information 
(since David can't linearize the stuff that we already merged), but in 
_theory_ what David does actually does remove the historical context.

So "git-rebase" is a tool that is designed to allow maintainers to (as the 
command says) rebase their own development and re-linearize it, so that 
they don't see the real history. It's basically the reverse of what Len is 
doing - Len mixes up his history with other peoples history in order to 
keep them in sync, while David bassically "re-does" his history to be on 
top of mine (to keep it _separate_).

The "git-rebase" means that David will always see the development he has 
done/merged as being "on top" of whatever my most recent tree is. It's 
actually a bit scary, because if something goes wrong when David re-bases 
things, he'll have to clean things up by hand, and git won't help him 
much, but hey, it works for him because (a) things seldom go wrong and (b) 
he appears so comfortable with the tool that he _can_ fix things up when 
they do go wrong.

And yes, git-rebase can be very convenient. It has some problems too 
(which is the other reason I don't try to convince other maintainers to 
use it): because it re-writes history, a change that _might_ have worked 
in its original place in history might no longer work after a rebase if it 
depended on something subtle that used to be true but no longer is in the 
new place that it has been rebased to.

Which just means that a commit that was tested and found to be working 
might suddenly not work any more, which can be very surprising ("But I 
didn't change anything!").

On the other hand, this is no different from doing a merge of two 
independent streams of development, and getting a new bug that didn't 
exist in either of the two, just because they changed the assumptions of 
each other (ie not a _mismerge_, but simply two developers changing 
something that the other depended on it, and the bug only appears when 
both the working trees are merged and the end result no longer works).

So my suggested git usage is to _not_ play games. Neither do too-frequent
merges _nor_ play games with git-rebase.

That said, git-rebase (and associated tools like "git-cherry-pick" etc) 
can be a very powerful tool, especially if you've screwed something up, 
and want to clean things up. Re-doing history because you realized that a 
you did something stupid that you don't want to admit to anybody else.

So trying out git-rebase and git-cherry-pick just in case you decide to 
want to use them might be worthwhile. Making it part of your daily routine 
like David has done? Somewhat questionable, but hey, it seems to be 
working for David, and it does make some things much easier, so..

			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/