Re: Newbie grief
- From
- Rich Pixley <rich.pixley@palm.com>
- Date
- May 1, 2012, 01:55 UTC
- Message-ID
- <4F9F427F.7000100@palm.com>
- In-Reply-To
- <7vr4v4d6um.fsf@alter.siamese.dyndns.org>
On 4/30/12 18:32 , Junio C Hamano wrote:
Show 15 quoted lines
> Rich Pixley<rich.pixley@palm.com> 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.
Show 10 quoted lines
> 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