RE: git pull on Linux/ACPI release tree

[Linus Torvalds <torvalds@osdl.org>]

On Sun, 8 Jan 2006, Brown, Len wrote:
>
> Perhaps the tools should try to support what "a lot of people"
> expect, rather than making "a lot of people" do extra work
> because of the tools?
> 
> Call me old fashioned, but I believe that tools are supposed to
> make work easier, not harder.

They DO.

Len, you're doing EXTRA WORK that is pointless.

Just stop doing the automated merges. Problems solved. It really is that 
easy. Don't do what David suggests - he does it because he's apparently 
_so_ comfortable with things that he prefers to do extra work just to keep 
his trees extra clean (I actually would disagree - but git makes that 
fairly easy to do, so if you prefer to have as linear a history as 
possible, you can do it with git pretty easily).

Now, I'm only complaining about _automated_ merges. If you have a reason 
to worry about my tree having clashes with your tree, do a real merge. For 
example, in your latest pull, you had a 

	"pull linus into release branch"

merge, where you merged my v2.6.15 tree. That makes perfect sense.

What I object to is that there were _also_ two automated merges within ten 
hours or each other, with absolutely _zero_ development in your tree in 
between. Why did you do that in your development tree? By _definition_ you 
had done zero development. You just tracked the development in _my_ tree.

In case you wonder, the two commits I'm talking about are:

	add5b5ee992e40c9cd8697ea94c223628be162a7
	25da0974601fc8096461f3d3f7ca3aab8e79adfb

and neither of them have any reason to be in a development tree. You 
didn't develop them.

They are real merges, because you had a trivial patch in your tree 
(changing the acpi-devel mailing list address) that I didn't have, so when 
you pulled, your end result was thus always different from something I had 
(so you did a real "merge", even though it was totally trivial), but the 
point is that there is a difference between "the ACPI development tree" 
and "the tree that has random ACPI patches and then tracks Linus' tree as 
closely as possible".

See?

That's the most egregious example. There's two unnecessary pulls on 
December 28 and 29th too (commits 0a5296dc and c1a959d8).

You can do

	gitk 0aec63e..f9a204e1 

to see exactly what I see when I pulled from you. 11 commits, 5 of which 
are just trivial merges that are no development, just tracking _my_ tree. 
Of those, one makes sense (tracking a release).

(NOTE NOTE NOTE! It does make sense to track my tree in case you do big 
changes and you worry about clashes. Then you would want to synchronize 
those big changes with my changes, so that you can resolve any clashes 
early. So I'm not saying that tracking trees is always bad: I'm saying 
that doing so _unnecessarily_ is bad, because it adds no value, and it 
just makes the history harder to read).

Now, most people don't read the history. It gets messy enough quickly 
enough that it's hard to read anyway over time. My tree has tons of _real_ 
merges anyway, since it's by definition the one that is used for most 
synchronization, so my tree is always pretty hard to follow.

But my guess is that this probably makes it harder for _you_ to see what 
you've done too. If you didn't merge with me, then "git log" would show 
just your own changes at the top, and that's likely what you care most 
about anyway, no?

Also, if you didn't pull from me, and you decided that you needed to re-do 
your tree (let's say that you notice that one of your commits was bad 
_before_ you ask me to pull from your tree), then you'd also have an 
easier time re-creating your own development without that buggy change, 
exactly because _your_ tree wouldn't have my changed mixed up in it.

So your merges likely make git harder to use for you, not easier.

		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/