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