Re: optimising a push by fetching objects from nearby repos

["Storm-Olsen, Marius" <Marius.Storm-Olsen@student.bi.no>]

On 5/10/2014 9:10 PM, Sitaram Chamarty wrote:
> On 05/11/2014 07:04 AM, Storm-Olsen, Marius wrote:
>> On 5/10/2014 8:04 PM, Sitaram Chamarty wrote: 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.

You can probably get the managers to do a fork without alternates too.

Also, it doesn't matter if you have already cloned from the original 
repo remotely. If you use the git manager to clone the original repo on 
the server, and you push to your new repo, only your changes will go 
back over the wire. The git protocol will figure out only which objects 
are missing to complete the new HEAD, and send those.

So
    1. Clone remote repo
    2. Hack hack hack
    3. Fork repo on server
    4. Push changes to your own remote repo
is equally efficient.


>> 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]).

It's similar, but security issues come into play due to the swapped 
direction, which is why I think it's wrong to place it in the push 
command. Now, having the 'borrow' complement to 'reference' in Git seems 
like a good idea, and should work for your case too, but IMO should be 
configured with in the security context of the repo manager, and not on 
an individual push. *shrug*


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

Absolutely, and I think that's how everyone perceived it :) It's a good 
idea, with some tweaks, I think.


-- 
.marius