From: Sitaram Chamarty Date: Sun, 11 May 2014 02:10:36 GMT Subject: Re: optimising a push by fetching objects from nearby repos Message-ID: <536EDC1C.5040101@gmail.com> In-Reply-To: <1399772049733.13154@student.bi.no> On 05/11/2014 07:04 AM, Storm-Olsen, Marius wrote: > 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. Gitolite already has a "fork" command that does that (though it uses "-l", not alternates). I specifically don't want to use alternates, and I also specifically am looking for something that activates on a push -- in the situations I am looking to optimise, the clone already happened. > 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. Yes, because of the "read access" check in my suggested procedure to handle this. (Otherwise this is as valid as the plan suggested for clone in Junior's email in [1]). [1]: http://thread.gmane.org/gmane.comp.version-control.git/243918/focus=245397 I will certainly be doing this in gitolite. The point of my post was to validate the flow with the *git* experts in case they catch something I missed, not to say "this should be done *in* git".