Re: optimising a push by fetching objects from nearby repos

[Sitaram Chamarty <sitaramc@gmail.com>]

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