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.
I had no good idea how to add this behavior to git clone as
the depth variable in git_transport_options struct (file transport.h)
uses value 0 for another meaning, so it would have need changes at
all places, where the transport options depth is being used
(e.g. fetch)
So I documented the current behavior, see attached patch.
Stefan Beller (1):
Documentation on depth option in git clone.
Documentation/git-clone.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
1.8.1.80.g3e293fb.dirty
---
Documentation/git-clone.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 7fefdb0..e76aa50 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -186,7 +186,8 @@ objects from the source repository into a pack in the cloned repository.
it, nor push from nor into it), but is adequate if you
are only interested in the recent history of a large project
with a long history, and would want to send in fixes
- as patches.
+ as patches. The depth should be at least 1. If it is 0 or
+ below, the cloned repository will not be shallow.
--single-branch::
Clone only the history leading to the tip of a single branch,
--
1.8.1.80.g3e293fb.dirty
Stefan Beller wrote:
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"?
On Tue, Jan 8, 2013 at 1:06 AM, Stefan Beller
[off-list ref] wrote:
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.
I had no good idea how to add this behavior to git clone as
the depth variable in git_transport_options struct (file transport.h)
uses value 0 for another meaning, so it would have need changes at
all places, where the transport options depth is being used
(e.g. fetch)
So I documented the current behavior, see attached patch.
If we choose not to do the off-by-one topic Junio suggested elsewhere
in the same thread, I think this document patch should be turned into
code instead. Just reject --depth=0 with an explanation. Users who are
hit by this will be caught without the need to read through the
document.
--
Duy