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

From: Jakub Narebski <jnareb@gmail.com>
Date: Oct 27, 2008, 12:48 UTC
Message-ID: <200810271348.39373.jnareb@gmail.com>
In-Reply-To: <200810271114.03406.arne_bab@web.de>

On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:

Show 13 quoted lines

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

Well, that is a question for filesystem designer, and VFS designer...

What I want to emphasize that perhaps Mercurial is optimized for "streaming access", but fully packed Git repository requires only single (well, up to details) mmap, which I think is even better.

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

DragonFly BSD developers? I think they would work on DragonFly BSD (eating one's own dogfood and all that...).

Sidenote: I don't know if DragonFly BSD is more like Linux kernel, or
as Linux distribution. It would be in my opinion good idea to ask
similar projects about the impressions about SCM they use (Linux kernel,
Android, ALT Linux distribution, Debian (build tools etc.), CRUX Linux
distribution, Exherbo, grml, Source Mage GNU/Linux for impressions
on their Git usage; OpenSolaris, Conary, Heretix, Linux HA, perhaps
Mozilla for impressions on their Mercurial usage;

IIRC ALSA moved from Mercurial to Git, so they could be of help there.

[...]

>> Git just uses different way to keep operations atomic, different way
>> of implementing transactions.

Show 5 quoted lines

>> 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)?

No, you can use create then rename to final place trick, making use
of the fact (assumption) that renames are atomic. And Git first write
data, then write references which are used to access this data (this
relies on pruning dangling objects).
 
I'm not saying that git does not use locks at all, because it does,
for example to edit config file, or update branch and its reflog as
atomic operation. But it needs locking in very few places.

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

There are differences: Mercurial from what I understand uses forward deltas (from older to never) while Git prefers recency order; delta chains in Git doesn't need to form single line, but can be forest of delta chains; Git searches for good delta basis from large range of objects (see pack.window); there is pack index which allow for random access as if objects were in loose format (resolving deltas behind the scenes).

I also don't know how Mercurial deals with binary files; in Git pack format uses binary delta from LibXDiff by Davide Libenzi (File Differential Library), heavy modified.

Show 7 quoted lines

>> 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, that also depends on _when_ did you try this. In older versions of Git pack file got from network (git:// and ssh:// protocols) was exploded into loose objects; now is kept if it is large enough, only expanding it to make it thick, self contained pack file.

Unless you used http:// protocol, which I think kept packs as they were, and as dumb protocol (along ftp:// and rsync://) depends on remote repository being well packed.

Show 7 quoted lines

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

Well, there is a difference between "git checkout ." and "git reset --hard", but it does not matter here.

By the way, the design of Git allowed to add lately new feature: "git checkout --merge <file>..." to recreate conflicted merge in specified paths. For example if you completely borked merge resolution, and want to start from scratch.

Show 9 quoted lines

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

Well, as shown in "Worse is better", evolved design wins (Lisp machines versus Unix) :-)

Show 5 quoted lines

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

Understanding Git "mental model" certainly helps.

[...]

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

But _that_ might be because you are used to Mercurial UI, isn't it?

-- 
Jakub Narebski
Poland