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