Cloning marks pack for .keep

Cloning marks pack for .keep

[Jean-Luc Herren]

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

Re: Cloning marks pack for .keep

[Shawn O. Pearce]

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.  ;-)

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.

Re: Cloning marks pack for .keep

[Teemu Likonen]

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

> 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.