Re: optimising a push by fetching objects from nearby repos

On 05/11/2014 07:04 AM, Storm-Olsen, Marius wrote:

On 5/10/2014 8:04 PM, Sitaram Chamarty wrote:

quoted

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.

...

quoted

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