Re: [PATCH] git clone depth of 0 not possible.
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Jan 8, 2013, 07:38 UTC
- Message-ID
- <CACsJy8D9+KHT=YfU0+rPCbs+AwxQOpfKzPChDhk8d-MMkRzZug@mail.gmail.com>
- In-Reply-To
- <7vip78go6b.fsf@alter.siamese.dyndns.org>
On Tue, Jan 8, 2013 at 1:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
>> Sounds buggy. Would anything break if we were to make --depth=1 mean >> "1 deep, including the tip commit"? > > As long as we do not change the meaning of the "shallow" count going > over the wire (i.e. the number we receive from the user will be > fudged, so that user's "depth 1" that used to mean "the tip and one > behind it" is expressed as "depth 2" at the end-user level, and we > send over the wire the number that corresponded to the old "depth > 1"), I do not think anything will break, and then --depth=0 may > magically start meaning "only the tip; its immediate parents will > not be transferred and recorded as the shallow boundary in the > receiving repository".
I'd rather we reserve 0 for unlimited fetch, something we haven't done so far [1]. And because "unlimited clone" with --depth does not make sense, --depth=0 should be rejected by git-clone.
[1] If we don't want to break the protocol, we could make depth 0xffffffff a special value as "unlimited" for newer git. Older git works most of the time, until some project exceeds 4G commit depth history.
-- Duy