Re: [PATCH v3 22/35] upload-pack: support shallow requests
- From
Stefan Beller <sbeller@google.com>
- Date
- Feb 7, 2018, 19:00 UTC
- Message-ID
- <CAGZ79kauMhgP4Gjm=yVKSDGh0-WMSpNVCJRamfjnANyO5SWXTQ@mail.gmail.com>
- In-Reply-To
- <20180207011312.189834-23-bmwill@google.com>
On Tue, Feb 6, 2018 at 5:12 PM, Brandon Williams <bmwill@google.com> wrote:
Show 23 quoted lines
> Add the 'shallow' feature to the protocol version 2 command 'fetch' > which indicates that the server supports shallow clients and deepen > requets. > > Signed-off-by: Brandon Williams <bmwill@google.com> > --- > Documentation/technical/protocol-v2.txt | 67 +++++++++++++++- > serve.c | 2 +- > t/t5701-git-serve.sh | 2 +- > upload-pack.c | 138 +++++++++++++++++++++++--------- > upload-pack.h | 3 + > 5 files changed, 173 insertions(+), 39 deletions(-) > > diff --git a/Documentation/technical/protocol-v2.txt b/Documentation/technical/protocol-v2.txt > index 4d5096dae..fedeb6b77 100644 > --- a/Documentation/technical/protocol-v2.txt > +++ b/Documentation/technical/protocol-v2.txt > @@ -201,12 +201,42 @@ packet-lines: > to its base by position in pack rather than by an oid. That is, > they can read OBJ_OFS_DELTA (ake type 6) in a packfile. > > + shallow <oid> > + A client must notify the server of all objects for which it only
s/all objects/all commits/ for preciseness
Show 8 quoted lines
> + has shallow copies of (meaning that it doesn't have the parents > + of a commit) by supplying a 'shallow <oid>' line for each such > + object so that the serve is aware of the limitations of the > + client's history. > + > + deepen <depth> > + Request that the fetch/clone should be shallow having a commit depth of > + <depth> relative to the remote side.
What does depth mean? number of commits, or number of edges? Are there any special numbers (-1, 0, 1, max int) ?
From reading ahead: "Cannot be used with deepen-since, but can be combined with deepen-relative" ?
Show 19 quoted lines
> + > + deepen-relative > + Requests that the semantics of the "deepen" command be changed > + to indicate that the depth requested is relative to the clients > + current shallow boundary, instead of relative to the remote > + refs. > + > + deepen-since <timestamp> > + Requests that the shallow clone/fetch should be cut at a > + specific time, instead of depth. Internally it's equivalent of > + doing "rev-list --max-age=<timestamp>". Cannot be used with > + "deepen". > + > + deepen-not <rev> > + Requests that the shallow clone/fetch should be cut at a > + specific revision specified by '<rev>', instead of a depth. > + Internally it's equivalent of doing "rev-list --not <rev>". > + Cannot be used with "deepen", but can be used with > + "deepen-since".
What happens if those are given in combination?