Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial

From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Date: Aug 2, 2007, 18:08 UTC
Message-ID: <46B21D82.5020802@ramsay1.demon.co.uk>
In-Reply-To: <7vr6mn5znm.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 16 quoted lines

> Are you suggesting to make -l the default for local, in other
> words?  I personally do not make local clone often enough that I
> am not disturbed having to type extra " -l" on the command line.
> 
> But giving a way to force "copy not hardlink" while still
> avoiding "the same as the networked case by doing pack transfer"
> overhead may be a good thing to do.
> 
> Perhaps if the destination is local,
> 
>          - if -s is given, just set up alternates, do nothing else;
>          - by default, do "always copy never hardlink";
>          - with -l, do "hardlink if possible";
> 
> Hmmmm...
>

About six weeks ago, I finally got around to installing Linux (ubuntu 7.04) on my laptop. Naturally, I cloned my sparse and git repositories over from the Windows XP partition. Unfortunately, that left me with a sparse repo that I could not modify; during the clone cpio copied the object directory, with perhaps a little too much fidelity, which resulted in a .git/objects tree with 555 permissions (both files and directories). [It also set the file timestamps with utime(), BTW]. A quick chmod fixed it up without problem, but still ...

When I cloned the git repo, however, I forgot the -l parameter and git-clone effectively did a "git-fetch-pack --all -k $repo", leaving me with a working, and fully repacked, repository. Nice.

So, I was about to suggest that when invoked with -l, if the object database cannot be linked, due to EXDEV for example, it should fall back to the "fetch-pack" behaviour. Since I don't have access to a large repo, I can't compare the filesystem-copy time versus the fetch-pack time for a "realistic" repo, but I suppose the copy would always be faster. Oh Well.

Just a data point.

ATB,

Ramsay Jones