From: Junio C Hamano <gitster@pobox.com>
To: Sitaram Chamarty <sitaramc@gmail.com>
Cc: "git\@vger.kernel.org" <git@vger.kernel.org>,
milki <milki@rescomp.berkeley.edu>
Subject: Re: optimising a push by fetching objects from nearby repos
Date: Sat, 10 May 2014 14:02:16 -0700 [thread overview]
Message-ID: <xmqqtx8xuz3b.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <536E2C19.3000202@gmail.com> (Sitaram Chamarty's message of "Sat, 10 May 2014 19:09:37 +0530")
Sitaram Chamarty <sitaramc@gmail.com> writes:
> Is there a trick to optimising a push by telling the receiver to pick up
> missing objects from some other repo on its own server, to cut down even
> more on network traffic?
>
> So, hypothetically,
>
> git push user@host:repo1 --look-for-objects-in=repo2
>
> I'm aware of the alternates mechanism, but that makes the dependency on
> the other repo sort-of permanent.
In the direction of fetching, this may be give a good starting point.
http://thread.gmane.org/gmane.comp.version-control.git/243918/focus=245397
In the direction of pushing, theoretically you could:
- define a new capability "look-for-objects-in" to pass the name of
the repository from "git push" to the "receive-pack";
- have "receive-pack" temporarily borrow from the named repository
(if the policy on the server side allows it), and accept the push;
- repack in order to dissociate the receiving repository from the
other repository it temporarily borrowed from.
which would be the natural inverse of the approach suggested in the
"Can I borrow just temporarily while cloning?" thread.
But I haven't thought things through with respect to what else need
to be modified to make sure this does not have adverse interaction
with simultaneous pushes into the same repository, which would make
it harder to solve for "receive-pack" than for "clone/fetch".
next prev parent reply other threads:[~2014-05-10 21:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-10 13:39 optimising a push by fetching objects from nearby repos Sitaram Chamarty
2014-05-10 13:54 ` Duy Nguyen
2014-05-10 17:23 ` brian m. carlson
2014-05-10 17:32 ` milki
2014-05-10 20:04 ` brian m. carlson
2014-05-10 21:02 ` Junio C Hamano [this message]
2014-05-11 1:04 ` Sitaram Chamarty
2014-05-11 1:34 ` Storm-Olsen, Marius
2014-05-11 2:10 ` Sitaram Chamarty
2014-05-11 3:11 ` Storm-Olsen, Marius
2014-05-11 5:21 ` Sitaram Chamarty
2014-05-11 18:04 ` Junio C Hamano
2014-05-12 1:50 ` Sitaram Chamarty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqtx8xuz3b.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=milki@rescomp.berkeley.edu \
--cc=sitaramc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.