[Monotone-devel] Re: linus talk on git

[Bruce Stephens]

Derek Scherger <address@hidden> writes:

[...]

> The ui/command-set in git seems complicated and somewhat strange though.
> For example the fact that pull does fetch+merge seems a bit odd coming
> from monotone. It almost seems like "fetch" should have been called
> "pull" and "merge" could have been called "update" to maintain some
> command consistency.

The UI still seems pretty bad, but 1.5.1 is vastly better than
whenever I last looked at it, so they're clearly improving.

> In terms of performance, I did a very quick test today on a ~30,000 file
> tree and git status took ~0.6 seconds while monotone (with inodeprints
> on) took ~3.5 seconds. Personally, ~3.5 seconds doesn't really offend me
> and I'm curious as to how much sha1 consistency checking git is doing
> generally when compared with monotone. I suspect it's doing somewhat
> less verification of things.

I agree; it's been some time since monotone's performance really
bothered me.

I think what I like in git is the idea that branch names don't matter,
and that (when appropriate) actual work can disappear, too.

I work in an environment where we do code review (currently before any
kind of integration), and sometimes the result of the review is that
that bit of work is replaced by other work before integration.  That
feels like it might be doable using certs (maybe require two or three
branch certs before anyone trusts revisions or something), but it
feels much cleaner to use git, at present.

I'm not particularly bothered about keeping redundant work (which in
git could vanish); I am worried about ending up with zillions of
branches which have names we no longer like and which were only of
relevance for a few days anyway.  And should we not use branches so
much, I worry about ending up with experimental forks where someone's
deleted files, which then just get in the way.

(I agree that policy branches may well solve all these issues---that's
certainly the kind of thing they're aimed at making possible.  But I
think we want to change soonish, and I don't see policy branches being
usable in the relevant timescale.  (I'm currently not considering
mercurial because git's MinGW port seems OK, and because I don't have
a clear understanding of mercurial's local branches: they look a bit
too new, and not enough like git's nicely simple idea.))

> Anyway, I should play around with it some more, it does seem reasonable
> and there's nothing wrong with fast!

And there's that, too.  git's just that much faster that I suspect (as
the talk suggests) there's ways of using it that just wouldn't suggest
themselves otherwise.