[Top][All Lists]
[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 :-}