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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
