git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: optimising a push by fetching objects from nearby repos

From
SMStorm-Olsen, Marius <marius.storm-olsen@student.bi.no>
Date
May 11, 2014, 03:11 UTC
Message-ID
<1399777917522.41294@student.bi.no>
In-Reply-To
<536EDC1C.5040101@gmail.com>
On 5/10/2014 9:10 PM, Sitaram Chamarty wrote:
Show 11 quoted lines
> 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.
Show 11 quoted lines
>> 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*

Show 6 quoted lines
> [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
Previous: Sitaram ChamartyNext: Sitaram Chamarty
Message 10 of 13 in “optimising a push by fetching objects from nearby repos”
  1. Sitaram ChamartyMay 10, 2014
  2. Duy NguyenMay 10, 2014
  3. brian m. carlsonMay 10, 2014
  4. milkiMay 10, 2014
  5. brian m. carlsonMay 10, 2014
  6. Junio C HamanoMay 10, 2014
  7. Sitaram ChamartyMay 11, 2014
  8. Storm-Olsen, MariusMay 11, 2014
  9. Sitaram ChamartyMay 11, 2014
  10. Storm-Olsen, MariusMay 11, 2014
  11. Sitaram ChamartyMay 11, 2014
  12. Junio C HamanoMay 11, 2014
  13. Sitaram ChamartyMay 12, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.