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. -- .marius -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html