Promoting the use of Mercurial; was: Re: gnome dvcs survey results

Theodore Tso tytso at mit.edu
Fri Jan 9 10:39:25 CST 2009


On Fri, Jan 09, 2009 at 03:30:40AM -0600, Matt Mackall wrote:
> The two big things to me are general baroqueness and packing. As someone
> who's been maintaining a git converter for three years, I've been bitten
> by it numerous times. For instance, git converts non-ascii filenames in
> log messages to an octal-escaped form (see issue1360). Git diffs? Clever
> but hacky. If I were coming up with a replacement for the standard diff
> format, I think I would have done things a bit differently. Base85? A
> maze of twisty little passages..

Heh.  I guess it shouldn't be surprising, but these are mostly
internal issues that mostly developers would see.  Git does output
non-ascii filenames in log messages in quoted form, mostly to make
life easier for shell scripts.  That's admittedly a botch, but it is
something you can turn off via a config option (core.quotepath=false).
There's been talk of changing the default in the future to be false,
but the default has been left true for backwards compatibility
concerns.

My personal take on how things are stored internally is, "De gustibus
non est disputandum".  For the most part, it really doesn't impact
most users, and in fact, for both Hg and git, unless you're hacking
the internal guts of those routines the low-level storage mechanisms,
whether it's blobs and packing or diffs and weaves, it really doesn't
matter that much, since everyone else just uses the abstractions that
are provided by each system.  There are a few things which are harder
one way than the other (i.e., merges involving file copies/merges on
one side, arbitrary garbage collection of branches on the others), but
that's what clever programmers are for.  ;-) If done well, users
shouldn't notice much of a difference.

> With the design constraints that tags must be a) modifiable and b) part
> of history, I think they do reasonably well given a difficult problem
> space. Git has different constraints.

So I'm curious --- why is having tags as part of history so important
to you; what workflows does this allow?  I haven't seen graphical
tools that plot the movement of tags over time, for example.  The one
thing I can think of is if your tree only has one tip, the SHA-1 hash
of that tip implies, securely, the location of all global tags in the
tree.  As a result, for simple repositories where there is only one
tip, and everyone agrees on that tip, the need for PGP signed tags is
much less, since you get that security from the SHA-1 hash of the tip.
(Of course, someone could sneak in a modified .hgtags file as part of
some other commit, but presumably there is accountability regarding
who made the commit available, and in any case Mercurial does support
PGP signed tags.)   

Are there other reasons or advantages to having tags be tracked as
part of the repository history?

						- Ted
     



More information about the Mercurial mailing list