monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Comparison of Monotone and git


From: William Uther
Subject: Re: [Monotone-devel] Comparison of Monotone and git
Date: Thu, 19 Jun 2008 15:53:14 +1000


On 19/06/2008, at 1:02 PM, Matthew Nicholson wrote:


William Uther wrote:
The interesting part here is that Monotone has a global namespace for branches, whereas git has a local namespace for branches. By default in git you get a 1:1 local:remote branch name mapping, but you can rearrange that if you wish. This removes the need for centralised control of branch naming (policy branches) - it is all just local.

I like the idea of local branch namespaces. How do they implement it? Just use like the sha1 hash of various things as the true branch name and then map that to a texual name locally?

There is no global namespace for branches. Each local repository just keeps a list of the revisions that are at the head of each branch. When you pull from a remote repository, you get all their revisions, and you also store a local copy of the remote list of heads.

In monotone, you might pull, merge and update. In git, you'd do a similar thing - pull in the remote revisions, merge the remote head and the local head, then update your workspace to the local head. Git keeps track of the branches that are merged in, so this isn't too complex.

In monotone you can have multiple heads in a branch. In git you can't. You get a similar effect by having multiple branches. As the branches are only local, you can create them, use them as a monotone micro-branch, then merge it back and remove it.


I also find it interesting how little Git uses signing. Authors, changelogs, dates, etc are just stuck in the "manifest". That means that if any of them were to change, the revision id would change. Once you agree on the revision ID with someone, you've already agreed on the entire history.

It also means that they're not set up for transferring large numbers of certs. It would be relatively inefficient to have an automatic test system that added certs to every revision that passed the test suite. (The system would have to 'tag' each revision, and I don't believe git was designed for large numbers of tags.)

Be well,

Will       :-}





reply via email to

[Prev in Thread] Current Thread [Next in Thread]