Re: git pull on Linux/ACPI release tree

[Linus Torvalds <torvalds@osdl.org>]

On Sun, 8 Jan 2006, Luben Tuikov wrote:
>
> How about this usage (branch == tree):
> 
> Tree A    (your tree)
>   Tree B     (project B, dependent on Tree A)
>      Tree C     (project C, dependent on project B)
> 
> (i.e. diff(C-A) = diff(C-B) + diff(B-A))
> 
> Your tree is pulled into Tree A as often as your tree
> changes and it just fast forwards.
> 
> If I want to run project B with your latest tree, then
> I resolve/merge from tree A to tree B, compile B
> and run it.
> 
> If I want to run project C and project B with your
> latest tree, I resolve/merge from tree A to tree B
> and from tree B to tree C, compile C and run it.

No.

If tree B is based on _some_point_in_ A, then you just test that.

Because development line B is _independent_ of development line A. The 
fact that A changes doesn't change B - unless they have some real 
dependencies (which we should try to avoid).

So when you update ("fetch" in git parlance) branch A from me, that 
shouldn't affect branch B _nor_ branch C in any way. They clearly do not 
depend on the new stuff in A, since they do their own independent 
development. The fact that they _started_ at some random point during the 
development of A doesn't change that fact.

Now, if you want to _test_ the combined "new stuff in branch A and new 
stuff in branch B", feel free to do that. But realize that that is _not_ 
appropriate in either branch A _nor_ branch B.

So you'd be much better off with a separate "test" branch that you test 
stuff out in, and you then resolve ("pull" in git parlance) both branch A 
and branch B into that test branch.

See? Testing the combination of two branches doesn't actually have 
anything to do with either branch.

At some point, you decide that you want to merge what you've done in 
branch B. That's a _different_ and independent thing from deciding that 
you want to test the combination of two development branches. Clearly, 
it's great to test often, but that has nothing to do with releasing a 
branch.

> In such cases, are you saying that you'd prefer to
> pull from Tree B and Tree C (depending on your needs)?

I'm saying that mixing up the "let's test the combination" and "let's 
merge the two branches" are totally different things and should not be 
mixed up.

One is a random event (and then it makes sense to have, for example, a 
"automated test branch" that automatically merges every day and tests the 
results. I don't think you should expose those random merges to others, 
because they actually hinder the readability of the history for _both_ 
sides.

The other is a _directed_ event. It's the event of saying "branch B" is 
now ready to be merged. Usually that's best done by just saying "please 
pull now" - ie not by merging branch A into branch B (because that's not 
what you actually want, is it? What you want is for the development in 
branch B to show up in branch A - so you want branch A to do the pull).

Now, there's a third kind of event, which is again independent of the 
other two. It's more of a "let's try to keep the 'topic branch' 
development up-to-date with the branch we eventually want to merge the 
topic changes into". That's where you can now do two things:

 - David often "rebases" all of the changes in his "topic branch" (ie 
   conceptually "branch B") to the new top-of-head of "branch A". In other 
   words, he re-writes branch B entirely _as_if_ it was based on the newer 
   state "branch A". This is what "git rebase" is all about.

 - You can just pull from branch A into branch B, as a way to keep branch 
   B more up-to-date with the work in the "main trunk" or whatever. This 
   is ok, but it shouldn't be a common event. It should be something that 
   happens when you (for example) notice during testing that the test 
   merge no longer works cleanly. Or it might be "It's now been two weeks 
   since I synchronized, let's just synchronize to be safe".

See? I'm not objecting to topic branches pulling from my tree in general. 
It's just that they should have a _reason_. There's never any reason to 
pull into a development tree that you haven't done any development in, 
just because you also want to use that development tree for testing.

> Another question:
> Sometimes, a fix for project B finds its way into
> tree C (project C) (since C depended on that fix in B).
> Now I'd like to pull that particular fix, identified by
> its SHA, into project B, and nothing else, for this I can
> use git-cherry-pick, right?

That's one way. It's often the best way, especially if it's a really 
obvious bugfix. Or you could just fix it in your tree yourself. It will 
mean that the two branches have the same fix, but especially if it really 
is an identical fix, it won't be a merge problem.

You _can_ just decide to pull branch B into branch C, but that has a real 
problem, namely that it inexorably links the two together, so that nobody 
can then pull branch C without pulling indirectly branch B at the time 
that B->C merge happened. Sometimes that is ok. But it's nice to avoid it 
if you can.

But for example, if somebody fixed something in the trunk, and you 
actually do need that fix from the trunk for your topic branch 
development, then just doing a pull is _fine_. Now we're back to doing a 
merge that actually has a perfectly good reason.

IOW, don't cherry-pick to avoid merges when the merge really does make 
tons of sense. Merges are good, it's just that _too_ much of a good thing 
is bad.

> And lastly, is there a tool whereby I can "see" changes
> between repos, kind of like git-diff but being able to
> give URLs too?

No, all the good tools really are based on fetching (NOT "pulling") the 
other branch into your local tree as a separate branch. At that point, 
there are tons of wonderful tools you can use.

In other words, say that you want to know what has happened in another 
repository, at git://git.kernel.org/xyzzy. You aren't interested in the 
stuff that is already part of the trunk, you're just interested in what is 
only in that "xyzzy" branch, and how it relates to your code. 

What you'd do is

	git fetch git://git.kernel.org/xyzzy master:xyzzy-snapshot

which says "fetch the 'master' branch from that xyzzy repository, and call 
it 'xyzzy-snapshot' locally.

You can then (for example) fetch the code that is in _my_ tree by doign 
the same time (just call that branch 'linus'), and you can now do

	gitk linus..xyzzy-snapshot HEAD

which looks strange (you give "gitk" _both_ a range from the "linus" 
branch to the "xyzzy-snapshot" _and_ your own HEAD at this time), but what 
it basically does is that the "linus.." syntax tells git that you're not 
interested in anything that is already in the 'linus' branch.

So the above command line will actually graphically show _both_ your 
current HEAD branch _and_ the 'xyzzy-snapshot' branch, in parallel. You 
can see how (if at all) they are related to each other, ignoring all the 
commits that have already made it into my tree.

(You can also do "linus..HEAD" instead of just HEAD and effectively repeat 
the "don't show 'linus' branch any more" twice. It's perfectly equivalent, 
of course. You may also want to use the "-d" flag to "gitk" which tells it 
to show things in date order, instead of a simplified history order).

Or just do "what has xyzzy-snapshot that I do not have in my HEAD":

	git log HEAD..xyzzy-snapshot

(or gitk), or the other way around: what do _I_ have in my HEAD that 
hasn't been pushed to xyzzy-snapshot yet:

	git log xyzzy-snapshot..HEAD

(or do diffs, "git whatchanged -p", or whatever).

In other words, using a few different branches (you can make them up 
dynamically) can be very powerful.

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