Re: [PATCH] "git push": tellme-more protocol extension

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 20, 2008 at 12:58:24AM -0700, Junio C Hamano wrote:

> When both ends support this extension, the receiving end first says "I
> support tellme-more, and here are my refs".  The sending side, when it
> sees commits that it does not know about (e.g. "B" in the above example),
> can then ask "I do not know about B, but it probably is related to what I
> already have, so tell me more about it".
> 
> The receiving end then responds with list of commits that are ancestors of
> "B", and in the above example, the sender will find out that the recieving
> end also has "A".  After this exchange, the sending end can build a pack
> that contains objects between A..C, instead of having to send the full
> history leading to "C".

Hrm. It seems like we are sending a lot more data than we need. The
sender doesn't actually _care_ about A..B, which can be arbitrarily
long; he only cares about finding A.

I wonder if there's a way to for the _sender_ to claim "I have up to A",
and the receiver to send back an "OK, just send A..C." If the receiver
is currently at "B", then the sender can't figure it out from the refs
the receiver shows. But he might he might optimistically suggest it if
he has other refs pointing to "A" (like remotes/origin/master).

IOW, something like:

  [S connects to R]
  R: master is at B
  [S realizes he doesn't have B, so he shows his refs, without names]
  S: I have optimistically interesting commits: A, C
  R: I have A
  S: OK, here's C ^A

In the case that the receiver doesn't have any of those refs, then we
fall back to the old behavior. So basically rather than enumerating
the ancestors, we optimistically assume that things that are in refs are
likely to be of interest.

Two disadvantages I can think of:

  1. S actually "leaks" some knowledge about which commits he has to R
     (not refnames, but actual SHA1s). I don't know if we care about
     that or not.

  2. This can actually be _more_ network intensive than your proposal.
     It trades off sending all of the ancestors A..B for sending the tip
     of all of the refs. So if A..B is short, but you have a ton of
     local refs, it's a lose. You could maybe be smarter about the
     optimistic choice (e.g., "I'm talking with origin, therefore
     consider only refs/remotes/origin/*"). That also alleviates the
     "leak" problem since you are saying "I have this commit that I got
     from you before." But it doesn't kick in if you usually talk to one
     remote, but now are talking to a different, related one.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux