[PATCH] Do not fetch tags on new shallow clones

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The main purpose of shallow clones is to reduce download. Fetching
tags likely defeats this purpose because old-enough repos tend to have
a lot of tags, spreading across history, which may increase the number
of objects to download significantly.

For example, "git clone --depth=10 git://.../git.git" without changes
fetches ~16M (50k objects). The same command with changes fetches
~6.5M (10k objects).

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
---
 This could also be applied for normal clones. But I don't think
 there are many use cases for it, enough to deserve new --no-tags
 option.

 We should also fetch a single branch, but because branches are
 usually less crowded and stay close the tip, they do not produce too
 many extra objects. Let's leave it until somebody yells up.

 We should also fetch tags that reference to downloaded objects. But I
 don't know how fetch does that magic, so for now users have to do
 "git fetch" after cloning for tags. I have only gone as far as
 fetching tags along by setting TRANS_OPT_FOLLOWTAGS? Help?

 builtin/clone.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin/clone.c b/builtin/clone.c
index 86db954..abd8578 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -428,7 +428,7 @@ static struct ref *wanted_peer_refs(const struct ref *refs,
 	struct ref **tail = head ? &head->next : &local_refs;
 
 	get_fetch_map(refs, refspec, &tail, 0);
-	if (!option_mirror)
+	if (!option_mirror && !option_depth)
 		get_fetch_map(refs, tag_refspec, &tail, 0);
 
 	return local_refs;
-- 
1.7.8.36.g69ee2

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]