On 4/30/12 18:32 , Junio C Hamano wrote:
Rich Pixley<rich.pixley@xxxxxxxx> writes:
Git tracks your version of master separately from each other remote's
master. This is exactly dual/multiple heads.
No, it isn't at all.
Multiple heads are the idea that a single commit can "branch" in the
repository and that both commits can be HEADS of the same branch at
once in a single repository. This allows a potential collision to
exist in the repository and to be pushed and pulled through multiple
repositories.
I think your "not at all" thinking is a bit tainted by your knowing very
well how Hg does things,
Actually, I came up with the same design back in the early 90's when I
was working on CVS. I think the hg way of doing things is pretty
obvious once we think about it. You can't expect users to do manual
merges on a remote server. So the only thing you can reasonably do is
collect and propagate the collision with enough info that a human being
can put it back together later. Refusing the commit doesn't seem
reasonable to me.
The old approach from clearcase multisite where every repository owns
it's own unique branch, which shows up as a read-only branch in the
other repositories, is a nuisance because you have to constantly keep
merging or your geographic partitions drift. It's difficult enough to
keep disparate groups working in concert. Forcing them to do big merges
in batch frequently doesn't help. That's essentially what we're reduced
to with git.
The illusion that we're all working on the same branch, (mercurial,
monotone, etc), defaults to more frequent merges, and a much smaller
change tree when it comes to visualization.
but I do not think there is much fundamental
difference between what we do. Git just tends to be a bit more explicit
and encourages users to be also be more explicit.
When you integrate from the other side (say, "origin") by pulling, instead
of splitting the 'master' branch into two (i.e. ours and origin's), we
store what came from the origin in remotes/origin/master and let the user
merge it into his heads/master. Essentially, the same name 'master' is
split into two, between remotes/origin/ and heads/ namespace. We are just
more explicitly about the split.
I wouldn't call it explicit. That level of detail provides no features.
It's tedious extra work that could have been tracked and managed
automatically. The fact that it isn't tracked and managed automatically
prevents simple repository chaining of the sort I originally set out to
accomplish.
Similarly, when pushing, you could follow the same model by pushing your
change into remotes/pixley/master, instead of pushing directly to the
"master" branch, i.e. heads/master, and then merge the former to the
latter after push succeeds.
That presupposes that I own both repositories rather than working in a
cooperative environment.
Needless to say, you do not have to limit the splitting just to two.
Since everything is named, you can tell where each 'master' came from by
looking at the namespace (obviously this requires people to establish and
follow the naming convention).
Right. This is the sort of thing people write source code control
systems to manage. :).
--rich
--
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