threads / discuss / 14331

Cloning marks pack for .keep

Subject: Cloning marks pack for .keep

## tl;dr

3 messages between Jul 7, 2008 and Jul 8, 2008.

replies: 2people: 3as markdown or json

Jean-Luc Herren· Jul 7, 2008, 21:27 UTC · lore

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
Shawn O. Pearce· Jul 8, 2008, 04:46 UTC · re: Jean-Luc Herren · lore

Re: Cloning marks pack for .keep

Jean-Luc Herren <jlh@gmx.ch> wrote:
Show 8 quoted lines
> 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.

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.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 builtin-clone.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 7bcc664..7ee8275 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -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.
Teemu Likonen· Jul 8, 2008, 06:57 UTC · re: Shawn O. Pearce · lore

Re: Cloning marks pack for .keep

Shawn O. Pearce wrote (2008-07-08 04:46 +0000):
Show 13 quoted lines
> Jean-Luc Herren <jlh@gmx.ch> wrote:
> > 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.
> 
> 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.  ;-)

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.

← back to recent threads