[TxMt] Re: Distributed model for bundles

[Brian Mitchell]

On 8/11/07, Fred B <fredb7 at gmail.com> wrote:
> On 8/8/07, Brian Mitchell <binary42 at gmail.com> wrote:
> > I'm surprised you took that as an attack on mercurial(...)
>
> On 8/11/07, Jacob Rus <jacobolus at gmail.com> wrote:
>
> > Sorry... my post was certainly not intended as an attack on hg, or bzr,
> > or darcs, or any other system.
> >
> > But really, the day-to-day usage of git is not IMO a serious barrier to
> > its use by "non-power-users".  It's just not that hard IMO to do the
> > basic stuff.
>
> I don't think anybody has attacked Mercurial or other systems.
> It's just that after using a lot of those systems (hg, svk, git, darcs
> and bzr in a lesser way), Mercurial is my first choice and git the
> last one. I sincerely wonder why some people seems to favor git
> recently, because it's a lot less user friendly than other systems,
> IMHO.
>
> I just wanted to convince everyone to try both (if not more) systems
> before weighting for one, that's all.

Then please do be more careful. I can easily give examples of where
you were quite inaccurate:

> - Git is much more difficult to install than Mercurial. Even with
> MacPorts: e.g. Git needs new versions of openssh, openssl, curl,
> rsync, etc. and install more than 135 different commands! This take a
> lot of time and can be difficult if you have installed some of those
> outside of MacPorts. On Tiger, the only thing you need before
> installing Mercurial is upgrading Python to 2.4+. Then it takes 20
> sec.

So MacPorts updates some dependencies to ensure one has an up to date
environment. The phrase "Git needs new versions" is quite misleading.
Git does not require a number of those installations but the package
manager you are using has chosen those for you. Over that, both
require hefty compilation (Python is not a lightweight package itself
either) but it comes down to one easy command in both cases.

> - Documentation: Git install a man page for each command (~135) and
> have no user manual, not the easiest way to find information when you
> need it, IMO. Mercurial has 3 man pages and complete doc, check the
> [official site][1] and the unofficial [hg book][2] (check the
> comparison between Mercurial and other systems, BTW).

I think you ought to check the git website. There is indeed
documentation for each command with good coverage on practically
everything git can do but there are also documents on getting started,
moving from other systems, setting git up, and even a MANUAL [0]. I
find documentation in git a little sub-optimal but having used
mercurial in a number of cases I would put the to in similar cases.
The reason for so many man pages in git is that it documents and
exposes more than just the highest level commands. Git provides a lot
of low level stuff that can come in handy when you need it
(fortunately rare now that the interface has matured). Fortunately
people who want to make use of these commands (maybe for integration
into other high-level systems -- textmate?) aren't left in the dark.

> - I consider myself a power user and Git is definitely more difficult
> to learn and use than Mercurial. The all "index tree" concept adds
> unneeded complexity, IMHO. (Allan has a hard time making a Git bundle
> for TM because of that. See the [qit bundle thread][3].) I think that
> if git is chosen for TM bundles, there will be more git related
> questions on this list than anything else.

This is one important point but there is more to it than meets the eye.

Indeed, git is not simple to dive into if the frame of reference being
used is another version control system. The concepts in git are rather
simple and the documentation explains them well. The drawback is that
a lot of these concepts are new rather than shared with other systems
making it somewhat hard to start off running and expecting to
replicate everything done in a different system.

I've found that trying to understand the fundamentals helped me move
from the basic commands stage into a much larger range of commands. I
can now say that Git's design is rather simple... I just never
accepted that answer until I was able to see the complete thing in my
mind. Having gone through all of that, I am in the process of helping
my coworkers through a migration from Subversion to Git. It will
certainly be interesting but so far, they very quickly became capable
enough to do everything they did in Subversion.

Measuring learning curves with building a bundle is somewhat unfair as
well. Some of the things git does at an integration level are
certainly different from those at a basic user level. Again, git has
many levels of detail to choose from depending on your needs.

> - I read that a Git repository requires frequent manual "repacks" of
> its metadata. Mercurial repository needs no maintenance.

Repacking the object database is a simple command and does not need to
be done often. The main reason for the command is to optimize the
internal representation of objects. Git provides a rather efficient
storage system so repacking shouldn't need to be done unless you
either need to compress space usage or feel a performance hit after a
while. There are possibly ways to automate this but I don't consider
it a nuisance since I even bother with this more than once a week if
even that. I'm sure people could happily go for months in some cases.

> - AFAICT, Mercurial's source code is MUCH more clean and readable (and
> I'm not a big fan of Python).

Actually, having been involved in some research into some git pull
behavior, I have to say that git is rather nice. I can read C pretty
well and don't consider myself allergic to {}'s but pushing syntax
aside, there isn't much to complain about.

Some people do get annoyed by the fact that git has a load of shell
scripts surrounding the core git command. This is being worked on as a
summer of code project IIRC. Though... I guess I don't mind shell
scripts either since I come from the unix background in the first
place.

I think these sorts of points are far too anecdotal. I consider that
there is something valid behind some of them. You will have to try
harder to make those points more apparent or at least much more
accurate.

Anyway... I hope you see my point. I could lay down my own arguments
for Git but I'll say straight out that I'd be completely happy with
Mercurial as well. In the long run, anyone interested in version
control _should_ learn Git as it really does do some interesting
things. Mercurial has some interesting things as well. In fact, even
though darcs isn't the most qualified system, it is worth checking out
in the name of expanding the mind (I would not recommend the system
for textmate's use.. but that is a complicated topic coming from a
long time darcs user -- best avoided).

For the people who end up not having their favorite chose, tailor is a
wonderful tool (among other options in some cases). I recommend that
those who feel their options have been left out regroup and setup
something to allow everyone to work in harmony.

Brian.

[0] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
which was linked to from the front page.