{"thread":{"id":"14331","subject":"Cloning marks pack for .keep","startedAt":"2008-07-07T21:27:46Z","lastAt":"2008-07-08T06:57:46Z","messageCount":3,"participants":["Jean-Luc Herren","Shawn O. Pearce","Teemu Likonen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"82496","messageId":"48728A52.8080107@gmx.ch","threadId":"14331","inReplyTo":null,"subject":"Cloning marks pack for .keep","fromName":"Jean-Luc Herren","fromEmail":"jlh@gmx.ch","sentAt":"2008-07-07T21:27:46Z","receivedAt":"2008-07-07T21:27:46Z","isPatch":false,"sender":{"key":"jlh@gmx.ch","avatar":null},"body":"After cloning a local repository with \"git clone file://...\", the\nresulting repo had one big pack file, as expected, but also a\nmatching \".keep\" file.  Certainly this is a bug, isn't it?  The\nsame happens if I clone git.git.  I used git 1.5.6.1 but observed\nthe same with the current master.  I bisected this behavior to\ncommit fa740529 by Shawn O. Pearce (CC'ing him).  Since this dates\nback to 2007, I wonder if maybe only I am seeing this, but I\ncannot think of any reason for it.\n\n(I already mentioned this on IRC today.)\n\njlh\n"},{"id":"82548","messageId":"20080708044606.GC2542@spearce.org","threadId":"14331","inReplyTo":"48728A52.8080107@gmx.ch","subject":"Re: Cloning marks pack for .keep","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-07-08T04:46:06Z","receivedAt":"2008-07-08T04:46:06Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jean-Luc Herren <jlh@gmx.ch> wrote:\n> After cloning a local repository with \"git clone file://...\", the\n> resulting repo had one big pack file, as expected, but also a\n> matching \".keep\" file.  Certainly this is a bug, isn't it?  The\n> same happens if I clone git.git.  I used git 1.5.6.1 but observed\n> the same with the current master.  I bisected this behavior to\n> commit fa740529 by Shawn O. Pearce (CC'ing him).  Since this dates\n> back to 2007, I wonder if maybe only I am seeing this, but I\n> cannot think of any reason for it.\n\nThis is a known issue to me; I have been seeing this behavior\nmyself since probably fa74 hit next.  I just don't clone often\nso I've never thought about it much.  ;-)\n\nI'm willing to bet its the hard-coded:\n\n+       args.lock_pack = 1;\n\ninside of fetch_refs_via_pack() that is causing the .keep file to\nstay around after the clone.  When this gets set the caller must\ndelete the transport->pack_lockfile (if non-null) once the refs\nhave all been updated to reference the objects downloaded into the\npack file.  Under git-clone all refs are new and there is little to\nno chance that someone issues \"git gc\" at the same time as the fetch\nis running, so git-clone never cleaned up the pack_lockfile.\n\nI think this would fix it.\n\n--8<--\nRemove unnecessary pack-*.keep file after successful git-clone\n\nOnce a clone is successful we no longer need to hold onto the\n.keep file created by the transport.  Delete the file so we\ncan later repack the complete repository.\n\nSigned-off-by: Shawn O. Pearce <spearce@spearce.org>\n---\n builtin-clone.c |    7 +++++--\n 1 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin-clone.c b/builtin-clone.c\nindex 7bcc664..7ee8275 100644\n--- a/builtin-clone.c\n+++ b/builtin-clone.c\n@@ -337,6 +337,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \tconst struct ref *refs, *head_points_at, *remote_head, *mapped_refs;\n \tchar branch_top[256], key[256], value[256];\n \tstruct strbuf reflog_msg;\n+\tstruct transport *transport = NULL;\n \n \tstruct refspec refspec;\n \n@@ -458,8 +459,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \t\trefs = clone_local(path, git_dir);\n \telse {\n \t\tstruct remote *remote = remote_get(argv[0]);\n-\t\tstruct transport *transport =\n-\t\t\ttransport_get(remote, remote->url[0]);\n+\t\ttransport = transport_get(remote, remote->url[0]);\n \n \t\tif (!transport->get_refs_list || !transport->fetch)\n \t\t\tdie(\"Don't know how to clone %s\", transport->url);\n@@ -529,6 +529,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)\n \t\toption_no_checkout = 1;\n \t}\n \n+\tif (transport)\n+\t\ttransport_unlock_pack(transport);\n+\n \tif (!option_no_checkout) {\n \t\tstruct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));\n \t\tstruct unpack_trees_options opts;\n-- \n1.5.6.74.g8a5e\n\n\n-- \nShawn.\n"},{"id":"82562","messageId":"20080708065746.GA3536@mithlond.arda.local","threadId":"14331","inReplyTo":"20080708044606.GC2542@spearce.org","subject":"Re: Cloning marks pack for .keep","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-07-08T06:57:46Z","receivedAt":"2008-07-08T06:57:46Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Shawn O. Pearce wrote (2008-07-08 04:46 +0000):\n\n> Jean-Luc Herren <jlh@gmx.ch> wrote:\n> > After cloning a local repository with \"git clone file://...\", the\n> > resulting repo had one big pack file, as expected, but also\n> > a matching \".keep\" file.  Certainly this is a bug, isn't it?  The\n> > same happens if I clone git.git.  I used git 1.5.6.1 but observed\n> > the same with the current master.  I bisected this behavior to\n> > commit fa740529 by Shawn O. Pearce (CC'ing him).  Since this dates\n> > back to 2007, I wonder if maybe only I am seeing this, but I cannot\n> > think of any reason for it.\n> \n> This is a known issue to me; I have been seeing this behavior myself\n> since probably fa74 hit next.  I just don't clone often so I've never\n> thought about it much.  ;-)\n\nEarlier I noticed that this issue sometimes causes the repository to\ngrow pretty much after \"git gc\" because .keep packs are not touched.\nThis was discussed two months ago:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/81856\n\nI tend to think that .keep packs are not good idea at least for small\nand medium sized repos. For _really_ big ones I'm not sure.\n"}]}