From: Josef Wolf <jw@raven.inka.de>
To: git@vger.kernel.org
Subject: Re: Re-Transmission of blobs?
Date: Wed, 11 Sep 2013 13:27:58 +0200 [thread overview]
Message-ID: <20130911112758.GB14259@raven.wolf.lan> (raw)
In-Reply-To: <xmqqsixcy395.fsf@gitster.dls.corp.google.com>
On Di, Sep 10, 2013 at 10:51:02 -0700, Junio C Hamano wrote:
> Consider this simple history with only a handful of commits (as
> usual, time flows from left to right):
>
> E
> /
> A---B---C---D
>
> where D is at the tip of the sending side, E is at the tip of the
> receiving side. The exchange goes roughly like this:
>
> (receiving side): what do you have?
>
> (sending side): my tip is at D.
>
> (receiving side): D? I've never heard of it --- please give it
> to me. I have E.
At this point, why would the receiving side not tell all the heads it knows
about? That would enable the sending side to see whether it knows any of those
commits. It then would be able to remove from the sending list all the objects
that can be reached from the commits it knows about.
> (sending side): E? I don't know about it; must be something you
> created since you forked from me. Tell me about
> its ancestors.
This is not exactly true. In the example I had given, the sending side has all
three commits: C, D and E. So the sending side has no reason to say that it
doesn't know anything about E. Therefore the sending side has all information
it needs to deduce exactly which objects need to be sent to the receiving side.
What needs to be sent are all the objects in C..D but without all the objects
in C..E. I guess this operation would be called set-difference in english.
And if the receiving side would have told that it has heads X Y Z in addition,
and the sending side happens to have Y, then the sending side could in
addition remove any objects that can be reached from Y from the sending list.
--
Josef Wolf
jw@raven.inka.de
next prev parent reply other threads:[~2013-09-11 11:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-10 13:08 Re-Transmission of blobs? Josef Wolf
2013-09-10 17:51 ` Junio C Hamano
2013-09-11 11:27 ` Josef Wolf [this message]
2013-09-11 17:14 ` Junio C Hamano
2013-09-12 7:42 ` Josef Wolf
2013-09-12 9:23 ` Jeff King
2013-09-12 10:35 ` Josef Wolf
2013-09-12 19:44 ` Jeff King
2013-09-13 10:09 ` Josef Wolf
2013-09-16 21:55 ` Jeff King
2013-09-20 9:27 ` Josef Wolf
2013-09-24 7:36 ` Jeff King
2013-09-24 20:36 ` Josef Wolf
2013-09-12 12:45 ` Pyeron, Jason J CTR (US)
2013-09-12 19:56 ` Jeff King
2013-09-12 20:06 ` Pyeron, Jason J CTR (US)
2013-09-13 10:23 ` Josef Wolf
2013-09-13 11:51 ` Jason Pyeron
2013-09-13 12:16 ` Duy Nguyen
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=20130911112758.GB14259@raven.wolf.lan \
--to=jw@raven.inka.de \
--cc=git@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).