Re: [VOTE] git versus mercurial (for DragonflyBSD)

From: Arne Babenhauserheide <arne_bab@web.de>
Date: Oct 27, 2008, 10:14 UTC
Message-ID: <200810271114.03406.arne_bab@web.de>
In-Reply-To: <200810271041.54511.jnareb@gmail.com>

Am Montag 27 Oktober 2008 10:41:53 schrieb Jakub Narebski:

Show 8 quoted lines

> > If you tell a disk "give me files a, b, c, d, e, f (of the whole abc)",
> > it is faster then if you tell it "give me files a k p q s t", because the
> > filesystem can easier optimize that call.
>
> I would expect _good_ filesystem to be able to optimize this call as
> well. As I said it looks like Mercurial and Git are optimized for
> different cases: Git relies on filesystem for caching, and optimizes
> for warm cache performance.

The problem is by which knowledge the filesystem should optimize this call when it is storing the files in the first place.

Show 6 quoted lines

> > relying on crontab which might not be available in all systems (I only
> > use GNU/Linux, but what about friends of mine who have to use Windows?)
>
> But that doesn't matter in the context of this discussion, which is
> DragonflyBSD; worse or better support for MS Windows doesn't matter
> here, does it?

It only matters, if some developers are forced to work on WIndows machines at times.

Show 6 quoted lines

> > But Mercurial normally works on standard filesystems, so this isn't the
> > case for normal operations.
>
> Mercurial implements transactions as a way to keeping operations atomic.
> So I don't know what you mean by "normally works on standard filesystem"
> here.

I just meant "databases are a bit off topic" :)

Show 5 quoted lines

> > You could say, though, that git implements a very simple transaction
> > model: Keep all old data until it gets purged explicitely.
>
> Git just uses different way to keep operations atomic, different way
> of implementing transactions.

That's what I wanted to express.

> And probably requires transactions and locks for that. Git simply uses
> atomic write solution for atomic update of references.

Doesn't atomic write also need locks, though on a lower level (to ensure atomicity)?

> Behind the scenes, at a lower level, Git does necessary delta resolving.
> Delta chains in packs have limited length (as they have in Mercurial).

So both do snapshots - they seem more and more similar to me :)

> The answer usually is: did you have this repository packed? I admit
> that it might be considered one of disadvantages of git, this having
> to do garbage collection from time to time... just like in C ;-)

I cloned from the official repositories.

I hope Linus had his repository packed :)

> Well, understanding "git checkout ." doesn't require understanding
> inner workings of git. Your friend was incorrect here. I'll agree
> though that it is a bit of quirk in UI[1] (but I use usually
> "git reset --hard" to reset to last committed state).

Damn - one more way how I could have archieved what I wanted... one more way I didn't find.

> Just Google for "Worse is Better". But what I actually mean that Git
> feature set and UI has evolved from very bare-bones plumbing, adding
> features and UI _as needed_, instead of being designed according to
> what designer thought it was needed.

And that's how it feels to me.

A great testing ground, but it developed too many stumbling blocks which keep me from trying things.

When I now use git, I only do the most basic operations: clone, pull, push, add, commit, checkout. When anything else arises, I check if it is worth the risk of having to read up for hours - and since that wasn't the case for the last few months, I then just ignore the problem or ask someone else if he can fix it.

As a contrast, when I encounter a problem with Mercurial, I simply check the commands for a moment and then try to solve it, and normally I have what I wanted within seconds to minutes.

Git instead bit me once too often.

I know that this isn't something which hits everyone and that it is subjective, but since it hit me, I'm wary of git, because in my view it isn't something for the majority of people - and you almost always have someone from that "majority" in your project.

I don't want people getting afraid of solving their own problems, so I avoid systems which bite so often, that they create fear (for example of losing much time on something which should be a side issue).

All in all it's a UI issue - while the git UI bit me quite often, the Mercurial UI just works.

Best wishes, Arne

-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :) -- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the history of free software. -- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt