All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Sitaram Chamarty <sitaramc@gmail.com>
Cc: "Storm-Olsen\, Marius" <Marius.Storm-Olsen@student.bi.no>,
	"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: Sun, 11 May 2014 11:04:38 -0700	[thread overview]
Message-ID: <xmqqbnv4ur7t.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <536F08C5.3010705@gmail.com> (Sitaram Chamarty's message of "Sun, 11 May 2014 10:51:09 +0530")

Sitaram Chamarty <sitaramc@gmail.com> writes:

> But what I was looking for was validation from git.git folks of the idea
> of replicating what "git clone -l" does, for an *existing* repo.
>
> For example, I'm assuming that bringing in only the objects -- without
> any of the refs pointing to them, making them all dangling objects --
> will still allow the optimisation to occur (i.e., git will still say "oh
> yeah I have these objects, even if they're dangling so I won't ask for
> them from the pusher" and not "oh these are dangling objects; so I don't
> recognise them from this perspective -- you'll have to send me those
> again").

So here is an educated guess by a git.git folk.  I haven't read the
codepath for some time, so I may be missing some details:

 - The set of objects sent over the wire in "push" direction is
   determined by the receiving end listing what it has to the
   sending end, and then the sending end excluding what the
   receiving end told that it already has.

 - The receiving end tells the sending end what it has by showing
   the names of its refs and their values.

Having otherwise dangling objects in your object store alone will
not make them reachable from the refs shown to the sending end.  But
there is another trick the receiving end employes.

 - The receiving end also includes the refs and their values that
   appear in the repository it borrows objects from its alternate
   repositories, when it tells what objects it already has to the
   sending end.

So what you "assumed" is not entirely correct---bringing in only the
objects will not give you any optimization.

But because we infer from the location of the object store
(i.e. "objects" directory) where the refs that point at these
borrowed objects exist (i.e. in "../refs" relative to that "objects"
directory) in order to make sure that we do not have to say "oh
these are dangling but we know their history is not broken", we
still get the same optimisation.

At least, that is the theory ;-)

  reply	other threads:[~2014-05-11 18:04 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
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 [this message]
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=xmqqbnv4ur7t.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Marius.Storm-Olsen@student.bi.no \
    --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.