On Tue, 17 Oct 2006, Aaron Bentley wrote:
>
> > That doesn't matter...
>
> It has significant UI impact.
Right. You have to do it your way, because of the "simple revision
numbers".
Which gets us back to where we started: "simple" is in the eye of the
beholder. I personally think that git revision naming is a lot simpler,
exactly because it doesn't impose arbitrary rules on users.
For example, what happens is that:
- you like the simple revision numbers
- that in turn means that you can never allow a mainline-merge to be done
by anybody else than the main maintainer
- that in turn means that the whole situation is no longer distributed,
it's more like a "disconnected access to a central repository"
The "main trunk matters" mentality (which has deep roots in CVS - don't
get me wrong, I don't think you're the first one to do this) is
fundamentally antithetical to truly distributed system, because it
basically assumes that some maintainer is "more important" than others.
That special maintainer is the maintainer whose merge-trunk is followed,
and whose revision numbers don't change when they are merged back.
That may even be _true_ in many cases. But please do realize that it's a
real issue, and that it has real impact - it does two things:
- it impacts the technology and workflow directly itself: "pull" and
"merge" are different: a central maintainer would tend to do a "merge",
and one more in the outskirts would tend to do more of a "pull",
expecting his work to then be merged back to the "trunk" at some later
point)
- it will result in _psychological_ damage, in the sense that there's
always one group that is the "trunk" group, and while you can pass the
baton around (like the perl people do), it's always clear who sits
centrally.
Maybe this is fine. It's certainly how most projects tend to work.
I'll just point out that one of my design goals for git was to make every
single repository 100% equal. That means that there MUST NOT be a "trunk",
or a special line of development. There is no "vendor branch". It's
something that a lot of people on the git lists understand now, but it
took a while for it to sink in - people used to believe that the "first
parent" of a merge was somehow special, and I had to point out several
times on the git list that no, that's not how it works - because the merge
might have been done by somebody _else_ than the person who you think of
as being "on the trunk".
So when I say that your "simple" revision numbers are totally broken and
horrible, I say that not because I think a number like "1.45.3.17" is
ugly, but because I think that the deeper _implications_ of using a number
like that is ugly. It implies one of two things:
- the numbers change all the time as things get merged both ways
OR
- people try to maintain a "trunk" mentality
and I think both of those situations are simply not good situations.
In git, the fact that everybody is on an equal footing is something that I
think is really good. For example, when I was away for effectively three
weeks during August, all the git-level merging for the kernel was done by
Greg KH.
And realize that he didn't use "my tree". No baton was passed. I emailed
with him (and some others) before-hand, so that everybody knew that I
expected to be just pull from Greg when I came back, but it was _his_ tree
that he merged in, and he just worked the same way I did.
And when I did come back, I did a "pull" from his tree. At no point is
there a big merge-commit with a sign saying
"I now merged all the work that Greg did while I was away"
No. Because the way git works, my pull just fast-forwarded my tree,
because while I was away, Greg's tree _was_ the main tree, thanks to the
fact that git believes that everybody is 100% equal.
So it's actually a big conceptual thing.
I'm actually very happy with the design of git, and a large part of that
is that I think the data structures and the basic design was really good.
Now, I know I'm smarter than anybody else ("Bow down before me, you
worthless scum"), but the thing is, the way to do good basic design isn't
actually to be really smart about it, but to try to have a few basic
concepts.
And the "every repository is equal" is one such concept. The naming
follows from that - you simply _cannot_ use numbers if everybody is on the
same footing (at least not _stable_ numbers).
Btw, BK did get this right. I didn't _like_ the naming in BK, and it was
numbers, but it worked. But it only worked when people understood that the
numbers were ephemeral, and it _did_ cause confusion. But hey, the
confusion wasn't _that_ big of a problem.
> Even if I agreed that the revision was meaningless, the cost of such a
> revision is miniscule.
No. The _cost_ of the revision is the "trunk mentality". THAT is the true
cost. The belief that there is one "main line of development".
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html