{"thread":{"id":"2151","subject":"[PATCH] git-clone: don't unpack objects","startedAt":"2005-10-19T12:43:41Z","lastAt":"2005-10-19T20:58:36Z","messageCount":5,"participants":["Timo Hirvonen","Junio C Hamano","Johannes Schindelin","Linus Torvalds"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"10280","messageId":"20051019154341.2aed6998.tihirvon@gmail.com","threadId":"2151","inReplyTo":null,"subject":"[PATCH] git-clone: don't unpack objects","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2005-10-19T12:43:41Z","receivedAt":"2005-10-19T12:43:41Z","isPatch":true,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"Pass --keep flag to git-clone-pack.\n\nSigned-off-by: Timo Hirvonen \n\n---\n\n git-clone.sh | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\napplies-to: 984b42b74993da2be26cd2b50ac1d3e74b0c4cd5\n63a266005116dd914c85b4c5f97d0e628f0b37ec\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 18e692a..152ba15 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -184,8 +184,8 @@ yes,yes)\n \t\t;;\n \t*)\n \t\tcd \"$D\" && case \"$upload_pack\" in\n-\t\t'') git-clone-pack $quiet \"$repo\" ;;\n-\t\t*) git-clone-pack $quiet \"$upload_pack\" \"$repo\" ;;\n+\t\t'') git-clone-pack $quiet --keep \"$repo\" ;;\n+\t\t*) git-clone-pack $quiet --keep \"$upload_pack\" \"$repo\" ;;\n \t\tesac\n \t\t;;\n \tesac\n---\n0.99.8.GIT\n"},{"id":"10293","messageId":"7v4q7d5kwo.fsf@assigned-by-dhcp.cox.net","threadId":"2151","inReplyTo":"20051019154341.2aed6998.tihirvon@gmail.com","subject":"Re: [PATCH] git-clone: don't unpack objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-19T20:09:11Z","receivedAt":"2005-10-19T20:09:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Timo Hirvonen writes:\n\n> Pass --keep flag to git-clone-pack.\n\nHmph. Unconditionally?\n\nI do not personally mind this change; I even have this in my\n$HOME/share/git-core/templates/config file:\n\n [clone]\n keeppack = 1\n\nAre there cases where you would do 'git clone' over git native\ntransport and want the resulting pack expanded?\n\nOne use pattern I could think of that you may not want to have\nthe keeppack behaviour is when you keep multiple, related\nforeign repositories. For example, I could do this:\n\n cd /tarpit\n git-clone git://kernel.org/pub/scm/.../torvalds/linux-2.6.git/ 2.6\n\n mkdir -p $HOME/share/git-core/templates/objects/info\n cat >$HOME/share/git-core/templates/objects/info/alternates <<\\EOF\n /tarpit/2.6/.git/objects\n EOF\n # disable clone.keeppack in the templates configuration as well.\n ed $HOME/share/git-core/templates/config\n\n cd /tarpit\n git-clone git://kernel.org/pub/scm/.../jgarzik/libata-dev.git/ ata\n\nThe new 'ata' repository created above is set up to borrow from\nthe cloned '2.6' repository, even before git-clone-pack is run\n(thanks to the alternates in the templates). git-clone-pack\nstill needs to download and unpack 100k objects, but most of\nthem are already available through alternates and does not hit\nthe disk. It ends up leaving about 1k unpacked object files\nthat are unique in ata repository. But we cannot do this if we\nsay --keep in git-clone unconditionally.\n\nBTW, probably a better way to do the above example would be\n(this time without funny templates trick):\n\n cd /tarpit\n git-clone git://kernel.org/pub/scm/.../torvalds/linux-2.6.git/ 2.6\n git-clone -l -s -n 2.6 ata\n\n cd ata\n mkdir .git/refs/2.6\n mv .git/refs/heads .git/refs/tags .git/refs/2.6/.\n git-fetch-pack git://kernel.org/pub/scm/.../jgarzik/libata-dev.git/ |\n while read sha1 path\n do\n\tcase \"$path\" in HEAD) continue ;; esac\n\tmkdir -p `dirname \".git/$path\"`\n \techo \"$sha1\" > \".git/$path\"\n done\n rm -fr .git/refs/2.6\n\nThis one asks the other side to send only 6.5k objects instead\nof the full cloning-and-discarding, so it achieves the same\nresult with a lot less burden on the network.\n\nSo in that sense, the first example that showed using --keep\ndoes a suboptimal thing does not qualify as a counterargument to\nyour change, because it already is doing something suboptimal.\n\nWhat do people on the list think?\n"},{"id":"10294","messageId":"Pine.LNX.4.63.0510192221240.17759@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2151","inReplyTo":"7v4q7d5kwo.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-clone: don't unpack objects","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-10-19T20:23:33Z","receivedAt":"2005-10-19T20:23:33Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 19 Oct 2005, Junio C Hamano wrote:\n\n> What do people on the list think?\n\nFor projects with a long history, it might make sense to do it \nunconditionally, but for young projects, the packs would be very small and \ninefficient.\n\nHowever, I cannot think of other use cases where \"--keep\" would not make \nsense, and since projects tend to get a long history, maybe it would be \ngood to introduce a \"--nokeep\" to git-clone.\n\nJM2C,\nDscho\n"},{"id":"10296","messageId":"Pine.LNX.4.64.0510191327560.3369@g5.osdl.org","threadId":"2151","inReplyTo":"7v4q7d5kwo.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-clone: don't unpack objects","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-19T20:31:53Z","receivedAt":"2005-10-19T20:31:53Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 19 Oct 2005, Junio C Hamano wrote:\n> \n> Are there cases where you would do 'git clone' over git native\n> transport and want the resulting pack expanded?\n\nNo, I think the unconditional --keep is fine for clone.\n\nWhat to do about incremental pulls is not as clear, but I think the clone \ncase is pretty much obvious these days.\n\nThe main reason for unpacking was that packs used to be \"strange\". These \ndays, packs are arguably the _common_ thing.\n\nNow, having tons and tons of small packs is probably worse than having \ntons and tons of individual files, but if people get used to doing \noccasional full repacks, that doesn't matter.\n\n\t\tLinus\n"},{"id":"10300","messageId":"7virvt441v.fsf@assigned-by-dhcp.cox.net","threadId":"2151","inReplyTo":"Pine.LNX.4.64.0510191327560.3369@g5.osdl.org","subject":"Re: [PATCH] git-clone: don't unpack objects","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-19T20:58:36Z","receivedAt":"2005-10-19T20:58:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> No, I think the unconditional --keep is fine for clone.\n>\n> What to do about incremental pulls is not as clear, but I think the clone \n> case is pretty much obvious these days.\n>\n> The main reason for unpacking was that packs used to be \"strange\". These \n> days, packs are arguably the _common_ thing.\n\nOK, that makes sense. \n\nI'd move this 'unconditional keep' to clone-pack. The --keep\nflag becomes a no-op.\n"}]}