[VOTE] git versus mercurial (for DragonflyBSD)

[Arne Babenhauserheide]

Am Montag 27 Oktober 2008 10:41:53 schrieb Jakub Narebski:
> > 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. 

> > 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. 

> > 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" :) 

> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://selenic.com/pipermail/mercurial/attachments/20081027/39203958/attachment.pgp