On 5/10/2014 8:04 PM, Sitaram Chamarty wrote:
> On 05/11/2014 02:32 AM, Junio C Hamano wrote: That's an interesting
> thread and it's recent too.  However, it's about clone (though the
> intro email mentions other commands also).
> I'm specifically interested in push efficiency right now.  When you
> "fork" someone's repo to your own space, and you push your fork to
> the same server, it ought to be able to get most of the common
> objects from disk (specifically, from the repo you forked), and only
> what extra you did from the network.
> I do have a way to do this in gitolite (haven't coded it yet; just
> thinking).  Gitolite lets you specify something to do before
> git-*-pack runs, and I was planning something like this:

And here you're poking the stick at the real solution to your problem.

Many of the Git repo managers will neatly set up a server-side repo 
clone for you, with alternates into the original repo saving both 
network and disk I/O.

So your work flow would instead be:
   1. Fork repo on server
   2. Remotely clone your own forked repo

I think it's more appropriate to handle this higher level operation 
within the security context of a git repo manager, rather than directly 
in git.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to