Re: [Monotone-devel] Re: linus talk on git

[Justin Patrin]

On 5/22/07, Derek Scherger <address@hidden> wrote:
> Brian May wrote:
> >>>>>> "Graydon" == Graydon Hoare <address@hidden> writes:
> >
> >     Graydon> Nuno Lucas wrote:
> >     >>> Maybe I got this wrong, but based on what I have seen so far
> >     >>> of this talk, I couldn't help but think that Linus didn't
> >     >>> consult the Monotone developers with his concerns about speed,
> >     >>> why it was slow, or how much work it would take to improve its
> >     >>> speed.
>
> I haven't really used git but I've read over some of the docs and
> certain aspects of the design seem quite nice (the blob/tree/commit
> structures for example). These are very similar to monotone and this
> nice design was also what originally attracted me to monotone. One thing
> Linus mentions in the talk is that a function moving from one file to
> another would be recognized by annotate because of the fact/way that git
> tracks content. This sounds interesting and I'm curious as to what it
> looks like in practice.
>
> 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.
>
> 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.

Assuming my understanding of monotone is correct, monotone checks the
sha1's on all of the history of the revision.

> From Linus' talk it sounds like git just checks to make sure that what
you checkout is the same as what was checked in, e.g. just checks the
sha1 of that revision and not the history.

Or maybe neither of my understandings is correct. :-/

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


--
Justin Patrin