Re: [RFC/PATCH 0/3] protocol v2
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Feb 28, 2015, 00:07 UTC
- Message-ID
- <CACsJy8AqRPm8ked+u0k83R2sFCE+XCGDEzeT_d4QsrKOOXUwLw@mail.gmail.com>
- In-Reply-To
- <xmqqioenhs4p.fsf@gitster.dls.corp.google.com>
On Sat, Feb 28, 2015 at 6:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
> Just for fun, I was trying to see if there is a hole in the current
> protocol that allows a new client to talk a valid v1 protocol
> exchange with existing, deployed servers without breaking, while
> letting it to know a new server that it is a new client and it does
> not want to get blasted by megabytes of ref advertisement.
> ...
> The idea is to find a request that can be sent as the first
> utterance by the client to an old server that is interpreted as a
> no-op and can be recognised by a new server as such a "no-op probe".
> ...
> And there _is_ a hole ;-). The parsing of "shallow " object name is
> done in such a way that an object name that passes get_sha1_hex()
> that results in a NULL return from parse_object() is _ignored_. So
> a new client can use "shallow 0{40}" as a no-op probe.
> ...
> I am _not_ proposing that we should go this route, at least not yet.
> I am merely pointing out that an in-place sidegrade from v1 to a
> protocol that avoids the megabyte-advertisement-at-the-beginning
> seems to be possible, as a food for thought.There may be another hole, if we send "want <empty-tree>", it looks like it will go through without causing errors. It's not exactly no-op because an empty tree object will be bundled in result pack. But that makes no difference in pratice. I didn't verify this though.
In the spirit of fun, I looked at how jgit handles this shallow line (because this is more like an implementation hole than protocol hole). I don't think jgit would ignore 0{40} the way C Git does. This SHA-1 will end up in shallowCommits set in upload-pack, then will be parsed as a commit. But even if the parsing is through, a non-empty shallowCommits set would disable pack bitmap. Fun is usually short..
PS. heh my "want empty-tree" hole is probably impl-specific too. Not sure if jgit also keeps empty tree available even if it does not exist.
-- Duy