Cloning marks pack for .keep

After cloning a local repository with "git clone file://...", the resulting repo had one big pack file, as expected, but also a matching ".keep" file. Certainly this is a bug, isn't it? The same happens if I clone git.git. I used git 1.5.6.1 but observed the same with the current master. I bisected this behavior to commit fa740529 by Shawn O. Pearce (CC'ing him). Since this dates back to 2007, I wonder if maybe only I am seeing this, but I cannot think of any reason for it.

(I already mentioned this on IRC today.)

jlh

This is a known issue to me; I have been seeing this behavior myself since probably fa74 hit next. I just don't clone often so I've never thought about it much. ;-)

I'm willing to bet its the hard-coded:

+ args.lock_pack = 1;

inside of fetch_refs_via_pack() that is causing the .keep file to stay around after the clone. When this gets set the caller must delete the transport->pack_lockfile (if non-null) once the refs have all been updated to reference the objects downloaded into the pack file. Under git-clone all refs are new and there is little to no chance that someone issues "git gc" at the same time as the fetch is running, so git-clone never cleaned up the pack_lockfile.

I think this would fix it.

--8<--
Remove unnecessary pack-*.keep file after successful git-clone

Once a clone is successful we no longer need to hold onto the .keep file created by the transport. Delete the file so we can later repack the complete repository.

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

index 7bcc664..7ee8275 100644
@@ -337,6 +337,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 	const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
 	char branch_top[256], key[256], value[256];
 	struct strbuf reflog_msg;
+	struct transport *transport = NULL;
 
 	struct refspec refspec;
 

@@ -458,8 +459,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 		refs = clone_local(path, git_dir);
 	else {
 		struct remote *remote = remote_get(argv[0]);
-		struct transport *transport =
-			transport_get(remote, remote->url[0]);
+		transport = transport_get(remote, remote->url[0]);
 
 		if (!transport->get_refs_list || !transport->fetch)
 			die("Don't know how to clone %s", transport->url);

@@ -529,6 +529,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 		option_no_checkout = 1;
 	}
 
+	if (transport)
+		transport_unlock_pack(transport);
+
 	if (!option_no_checkout) {
 		struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
 		struct unpack_trees_options opts;

1.5.6.74.g8a5e


-- 
Shawn.

Shawn O. Pearce wrote (2008-07-08 04:46 +0000):

Earlier I noticed that this issue sometimes causes the repository to grow pretty much after "git gc" because .keep packs are not touched. This was discussed two months ago:

http://thread.gmane.org/gmane.comp.version-control.git/81856

I tend to think that .keep packs are not good idea at least for small and medium sized repos. For _really_ big ones I'm not sure.