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

[Bruce Stephens]

William Uther <address@hidden> writes:

[...]

>     - Git only downloads one branch (and has some support for partial
> checkouts)

That's not true (the first part, the second is true).

I imagine the confusion happens because if you do "git clone ...",
then in that checkout "git branch" shows (probably) only "master".
But all the remote branches are still there (you can see those using
"git branch -r"), and you can work with those if you like "git log
origin/next", "git checkout -b next origin/next", etc.

[...]

>  * History rewriting:
>     - Git has an easy UI for re-writing history in a local repository
>       - The re-base command that allows patch sets to be cleaned up
> before submission
>       - There is no reason this couldn't be done in monotone, but it
> goes against the Monotone philosophy.  You'd end up using a bunch of
> mtn kill_rev_locally' style operations that Monotone considers
> dangerous.

I think it's more subtle and pervasive than that suggests.  I'm not
quite sure how to describe how it works, though.

A big part of the difference is in branches: in git, a branch is a
name given to a commit (that gets updated in the obvious ways in some
circumstances).  That is, a commit doesn't know which branches it
belongs to: that's determined by the commit DAG (commits know who
their parents are) and the collection of branches (which changes over
time and is almost always different in different copies of the
repository).

>  * Command structure:
>     - Git has a different command structure, more focussed on the
> particular development model for Linux.
>     - Git also started as a collection of orthogonal tools.  This
> means that it doesn't have a reputation for having a clean UI.  In
> practice, the high level UI for git now seems fine.

I think that's fair.  The various commands seem to have accumulated
from need rather than from following some deep design.  The result is
a system that's very simple in the middle, but with rather a mess of
commands around the outside that we actually use, each of which seemed
useful enough to someone at some time.  But the mess of commands tends
to obscure the clear design in the middle.

In practice, the command set is now OK, as you say.

[...]