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

[Theodore Tso <tytso@mit.edu>]

On Wed, Aug 01, 2007 at 03:15:25AM -0700, Junio C Hamano wrote:
> > 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