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

From: Theodore Tso <tytso@mit.edu>
Date: Aug 1, 2007, 22:03 UTC
Message-ID: <20070801220350.GD28106@thunk.org>
In-Reply-To: <7vr6mn5znm.fsf@assigned-by-dhcp.cox.net>

On Wed, Aug 01, 2007 at 03:15:25AM -0700, Junio C Hamano wrote:

Show 8 quoted lines

> > So would you accept a patch which adds a git-config variable which
> > specifies whether or not local clones should use hard links by default
> > (defaulting to yes), and which adds a --no-hard-links option to
> > git-clone to override the config option?
> 
> 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.

Yeah, essentially, with a git-config option (and comand-line option) to override the default for those people who are "squeamish" about git clone -l. Linus's suggestion of using file:// as a way to indicate non-local also makes a lot of sense to me.

> Perhaps if the destination is local,
> 
>          - if -s is given, just set up alternates, do nothing else;

As I understand it, the main objection with making -s the default is surprising result that could happen if you do a git-prune in the base repository which causes objects which are borrowed from the base repository via .git/objects/info/alternates, right?

What if git clone -s appended the repository which is borrowing objects via alternates to a file located in the base repository, .git/objects/info/shared-repos?

Then git-prune could also use the refs marked in each of the downstream repositories that are sharing objects with base repository and not make those objects go away. That way, git-gc --prune won't do anything surprising to any shared repositories, since it will scan those shared repositories automatically. Would that be considered acceptable? That way you can get instant clones even on filesystems that don't support hard links, such as Windows systems.

The way I would suggest doing it is once we implement support for .git/objects/info/shared-repos is to do the following with git-clone by default:

   	* If the source repo is specified via a file:// URL, per Linus's
          suggestion, do the clone via copying.

	* If the source repo is specified via a local pathname, and
          .git/objects/info/shared-repos in the source repository is
          writeable by the user who is doing the clone, then do a
          clone -s.

	* If the above fails, try clone -l

	* If the above fails, do a clone via copying over a new pack

Would this be acceptable? Patches to do the following should be fairly easy to whip up. Obviously this wouldn't be for 1.5.3. :-)

       	       	    	 	   	- Ted