Re: [PATCH] git clone depth of 0 not possible.
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:55:41
Junio C Hamano [off-list ref] writes:
Jonathan Nieder [off-list ref] writes:quoted
Stefan Beller wrote:quoted
Currently it is not possible to have a shallow depth of just 0, i.e. only one commit in that repository after cloning. The minimum number of commits is 2, caused by depth=1.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 do not mind carrying such a (technially) backward incompatible change in jn/clone-2.0-depth-off-by-one branch, keep it cooking in 'next' for a while and push it out together with other "2.0" topics in a future release ;-).
Speaking of --depth, I think in Git 2.0 we should fix the semantics
of "deepening" done with "git fetch".
Its "--depth" parameter is used to specify the new depth of the
history that you can tangle from the updated tip of remote tracking
branches, and it has a rather unpleasant ramifications.
Suppose you start from "git clone --depth=1 $there". You have the
today's snapshot, and one parent behind it. You keep working happily
with the code and then realize that you want to know a bit more
history behind the snapshot you started from.
(upstream)
---o---o---o---A---B
(you)
A---B
So you do:
$ git fetch --depth=3
(upstream)
---o---o---o---A---B---C---D---E---F---...---W---X---Y---Z
(you)
A---B W---X---Y---Z
But in the meantime, if the upstream accumulated 20+ commits, you
end up getting the commit at the updated tip of the upstream, and 3
generations of parents behind it. There will be a 10+ commit worth
of gap between the bottom of the new shallow history and the old tip
you have been working on, and the history becomes disjoint.
I think we need a protocol update to fix this; instead of sending
"Now I want your tips and N commits behind it, please update my
shallow bottom accordingly", which creates the above by giving you Z
and 3 generations back and updates your cut-off point to W, the
receiving end should be able to ask "I have a shallow history that
cuts off at these commits. I want to get the history leading up to
your tips, and also deepen the history further back from my current
cut-off points by N commits", so that you would instead end up with
something like this:
(you)
o---o---o---A---B---C---D---E---F---...---W---X---Y---Z
That is, truly "deepen my history by 3". We could call that "git
fetch --deepen=3" or something.