{"thread":{"id":"12378","subject":"Will git have a baseline feature or something alike?","startedAt":"2008-02-29T09:23:37Z","lastAt":"2008-03-02T21:29:37Z","messageCount":16,"participants":["eric miao","Sean","Karl Hasselström","Jakub Narebski","Sam Vilain","Nguyen Thai Ngoc Duy","Eyvind Bernhardsen","David Brown","Shawn O. Pearce","Jan Hudec","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"70372","messageId":"f17812d70802290123raa099bag17a6f7b89de65dd4@mail.gmail.com","threadId":"12378","inReplyTo":null,"subject":"Will git have a baseline feature or something alike?","fromName":"eric miao","fromEmail":"eric.y.miao@gmail.com","sentAt":"2008-02-29T09:23:37Z","receivedAt":"2008-02-29T09:23:37Z","isPatch":false,"sender":{"key":"eric.y.miao@gmail.com","avatar":"https://gravatar.com/avatar/45c500ae8c8098c06263f27289c260c327a27e2a27f37e015af556412acd6183?d=mp&s=160"},"body":"All,\n\nI kept a mirror of\n\nhttp://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n\nby a crontab task fetching the updated commits at midnight everyday.\n\nYet I found the repository now grows to be 1.2G without checking out\nanything. The checked out working tree of this is about 1.5G.\n\nI tried \"git prune\" and \"git repack\" but it still remains so large. The\ntrend of the kernel is still going to be enlarged. Thus I'm thinking\nof the possibility of a baseline feature. One can totally forget about\nthe history before that baseline, and start the development there\nafter.\n\nE.g.\n\n1. user downloads a released tarball\n2. and build a repository\n3. and \"git fetch\" will find the current repository is identical to\na baseline in the remote, and fetches only commits after\nthat baseline\n4. continue the development work\n\nThe above steps with current git will generate a totally different\nhash value for the files in the downloaded tarball, thus making\nit failed to fetch commits thereafter.\n\nI know the history is usually mixed with multiple branches, which\nmakes this baseline feature a bit difficult to implement. It should\nbe a nice feature, though.\n\n-- \nCheers\n- eric\n"},{"id":"70373","messageId":"BAYC1-PASMTP1509BFBE329A906C583BDCAE140@CEZ.ICE","threadId":"12378","inReplyTo":"f17812d70802290123raa099bag17a6f7b89de65dd4@mail.gmail.com","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2008-02-29T09:56:09Z","receivedAt":"2008-02-29T09:56:09Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Fri, 29 Feb 2008 17:23:37 +0800\n\"eric miao\" wrote:\n\n\nHi Eric,\n\n> I kept a mirror of\n> \n> http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> \n> by a crontab task fetching the updated commits at midnight everyday.\n> \n> Yet I found the repository now grows to be 1.2G without checking out\n> anything. The checked out working tree of this is about 1.5G.\n\nThere's something wrong in your setup, the entire kernel history should\ntake less than 200M.\n\n> I tried \"git prune\" and \"git repack\" but it still remains so large. The\n> trend of the kernel is still going to be enlarged. Thus I'm thinking\n> of the possibility of a baseline feature. One can totally forget about\n> the history before that baseline, and start the development there\n> after.\n\nGit provides \"shallow\" clones which essentially give you that ability\ntoday via the --depth option. While it won't automatically determine\na baseline, it avoids the need for you to download a tarball first.\n\nSean\n"},{"id":"70376","messageId":"20080229103837.GC14773@diana.vm.bytemark.co.uk","threadId":"12378","inReplyTo":"BAYC1-PASMTP1509BFBE329A906C583BDCAE140@CEZ.ICE","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-02-29T10:38:37Z","receivedAt":"2008-02-29T10:38:37Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-02-29 04:56:09 -0500, Sean wrote:\n\n> On Fri, 29 Feb 2008 17:23:37 +0800\n>\n> \"eric miao\" wrote:\n>\n> > Yet I found the repository now grows to be 1.2G without checking\n> > out anything. The checked out working tree of this is about 1.5G.\n>\n> There's something wrong in your setup, the entire kernel history\n> should take less than 200M.\n\nTry running \"git gc\".\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"70389","messageId":"m3tzjrkie4.fsf@localhost.localdomain","threadId":"12378","inReplyTo":"f17812d70802290123raa099bag17a6f7b89de65dd4@mail.gmail.com","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-29T13:21:45Z","receivedAt":"2008-02-29T13:21:45Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"eric miao\" writes:\n\n> I kept a mirror of\n> \n> http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> \n> by a crontab task fetching the updated commits at midnight everyday.\n> \n> Yet I found the repository now grows to be 1.2G without checking out\n> anything. The checked out working tree of this is about 1.5G.\n\nDid you (re)packed this repository, running \"git gc\", or \"git repack\"?\nCurrently git either downloads small packs, or loose objects; it needs\nto repack to make repository size smaller.\n\nBTW. the largest git repository is 1.6G OpenOffice.org conversion,\nwith > 2G checkout, and some large binary files under version\ncontrol. Mozilla and GCC, other large repos, got under 0.5G IIRC.\nSo kernel should be quite smaller.\n \n> I tried \"git prune\" and \"git repack\" but it still remains so large. The\n> trend of the kernel is still going to be enlarged. Thus I'm thinking\n> of the possibility of a baseline feature. One can totally forget about\n> the history before that baseline, and start the development there\n> after.\n\nThere is so called \"shallow clone\" feature, which allows to clone only\npart of history. Currently it dupports only --depth, i.e. number of\ncommits from tips; it could I guess support providing tag as\ndelimiter. (You are welcome to implement it ;-).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"70482","messageId":"47C8FFFC.3050901@vilain.net","threadId":"12378","inReplyTo":"m3tzjrkie4.fsf@localhost.localdomain","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-03-01T07:04:28Z","receivedAt":"2008-03-01T07:04:28Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> BTW. the largest git repository is 1.6G OpenOffice.org conversion,\n> with > 2G checkout, and some large binary files under version\n> control. Mozilla and GCC, other large repos, got under 0.5G IIRC.\n> So kernel should be quite smaller.\n\nI have an 8GB git-svn import of the KDE repository :-)\n\nSam.\n"},{"id":"70516","messageId":"200803011339.50978.jnareb@gmail.com","threadId":"12378","inReplyTo":"47C8FFFC.3050901@vilain.net","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-01T12:39:43Z","receivedAt":"2008-03-01T12:39:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 1 Mar 2008, Sam Vilain wrote:\n> Jakub Narebski wrote:\n>\n>> BTW. the largest git repository is 1.6G OpenOffice.org conversion,\n>> with > 2G checkout, and some large binary files under version\n>> control. Mozilla and GCC, other large repos, got under 0.5G IIRC.\n>> So kernel should be quite smaller.\n> \n> I have an 8GB git-svn import of the KDE repository :-)\n\nFirst, how large full checkout is? And how large Subversion repo?\nSecond, is this repository tightly packed (large window, big delta\nchain)?\n\nAnd last, KDE repos should most probably be split into submodules.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"70528","messageId":"47C95823.5090006@vilain.net","threadId":"12378","inReplyTo":"200803011339.50978.jnareb@gmail.com","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-03-01T13:20:35Z","receivedAt":"2008-03-01T13:20:35Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> On Sat, 1 Mar 2008, Sam Vilain wrote:\n>> Jakub Narebski wrote:\n>>\n>>> BTW. the largest git repository is 1.6G OpenOffice.org conversion,\n>>> with > 2G checkout, and some large binary files under version\n>>> control. Mozilla and GCC, other large repos, got under 0.5G IIRC.\n>>> So kernel should be quite smaller.\n>> I have an 8GB git-svn import of the KDE repository :-)\n> \n> First, how large full checkout is? \n\nHeh, haven't tried tbh.\n\n> And how large Subversion repo?\n\n48GB apparently. This repository is approx. 90% of the subversion\nrepository - I didn't prepare it.\n\n> Second, is this repository tightly packed (large window, big delta\n> chain)?\n\nYes, I don't have the details, though.\n\n> And last, KDE repos should most probably be split into submodules.\n\nMmm. Everyone always says that; what it really needs I think is someone\nto really take the conversion on board and come up with a workable plan\non this front. I think the counter-argument to this was \"but you always\nwant to have 70% of the repository checked out for development\".\nCounter-counter argument is \"yes but they don't always need to be deep\nclones\". Anyway, it's not my baby, just thought I'd let you know about\nit :-)\n\nSam.\n"},{"id":"70533","messageId":"f17812d70803010610o39cdf327x995c9e2e75a9edba@mail.gmail.com","threadId":"12378","inReplyTo":"m3tzjrkie4.fsf@localhost.localdomain","subject":"Re: Will git have a baseline feature or something alike?","fromName":"eric miao","fromEmail":"eric.y.miao@gmail.com","sentAt":"2008-03-01T14:10:31Z","receivedAt":"2008-03-01T14:10:31Z","isPatch":false,"sender":{"key":"eric.y.miao@gmail.com","avatar":"https://gravatar.com/avatar/45c500ae8c8098c06263f27289c260c327a27e2a27f37e015af556412acd6183?d=mp&s=160"},"body":"On Fri, Feb 29, 2008 at 9:21 PM, Jakub Narebski wrote:\n> \"eric miao\" writes:\n>\n> > I kept a mirror of\n> >\n> > http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> >\n> > by a crontab task fetching the updated commits at midnight everyday.\n> >\n> > Yet I found the repository now grows to be 1.2G without checking out\n> > anything. The checked out working tree of this is about 1.5G.\n>\n> Did you (re)packed this repository, running \"git gc\", or \"git repack\"?\n> Currently git either downloads small packs, or loose objects; it needs\n> to repack to make repository size smaller.\n>\n> BTW. the largest git repository is 1.6G OpenOffice.org conversion,\n> with > 2G checkout, and some large binary files under version\n> control. Mozilla and GCC, other large repos, got under 0.5G IIRC.\n> So kernel should be quite smaller.\n>\n>\n> > I tried \"git prune\" and \"git repack\" but it still remains so large. The\n> > trend of the kernel is still going to be enlarged. Thus I'm thinking\n> > of the possibility of a baseline feature. One can totally forget about\n> > the history before that baseline, and start the development there\n> > after.\n>\n> There is so called \"shallow clone\" feature, which allows to clone only\n> part of history. Currently it dupports only --depth, i.e. number of\n> commits from tips; it could I guess support providing tag as\n> delimiter. (You are welcome to implement it ;-).\n>\n\nI haven't ever used the shallow clone, but it looks still a bit different\nfrom what I thought originally, say, if I download linux-2.6.24.tar.bz2\nfrom kernel.org, that's about 40MB and should be a fair amount.\nI then unpack and \"git init\", I expect it to recognize it's a v2.6.24,\nand I can thereafter use \"git fetch\" to fetch those commits after\nv2.6.24 from git.kernel.org. Is this possible?\n\n> --\n> Jakub Narebski\n> Poland\n> ShadeHawk on #git\n>\n\n\n\n-- \nCheers\n- eric\n"},{"id":"70534","messageId":"fcaeb9bf0803010629v4894ad92ief4d5ef4257723e@mail.gmail.com","threadId":"12378","inReplyTo":"f17812d70803010610o39cdf327x995c9e2e75a9edba@mail.gmail.com","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-03-01T14:29:04Z","receivedAt":"2008-03-01T14:29:04Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Mar 1, 2008 at 9:10 PM, eric miao wrote:\n> On Fri, Feb 29, 2008 at 9:21 PM, Jakub Narebski wrote:\n> > \"eric miao\" writes:\n> >\n> > > I kept a mirror of\n> > >\n> > > http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> > >\n> > > by a crontab task fetching the updated commits at midnight everyday.\n> > >\n> > > Yet I found the repository now grows to be 1.2G without checking out\n> > > anything. The checked out working tree of this is about 1.5G.\n> >\n> > Did you (re)packed this repository, running \"git gc\", or \"git repack\"?\n> > Currently git either downloads small packs, or loose objects; it needs\n> > to repack to make repository size smaller.\n> >\n> > BTW. the largest git repository is 1.6G OpenOffice.org conversion,\n> > with > 2G checkout, and some large binary files under version\n> > control. Mozilla and GCC, other large repos, got under 0.5G IIRC.\n> > So kernel should be quite smaller.\n> >\n> >\n> > > I tried \"git prune\" and \"git repack\" but it still remains so large. The\n> > > trend of the kernel is still going to be enlarged. Thus I'm thinking\n> > > of the possibility of a baseline feature. One can totally forget about\n> > > the history before that baseline, and start the development there\n> > > after.\n> >\n> > There is so called \"shallow clone\" feature, which allows to clone only\n> > part of history. Currently it dupports only --depth, i.e. number of\n> > commits from tips; it could I guess support providing tag as\n> > delimiter. (You are welcome to implement it ;-).\n> >\n>\n> I haven't ever used the shallow clone, but it looks still a bit different\n> from what I thought originally, say, if I download linux-2.6.24.tar.bz2\n> from kernel.org, that's about 40MB and should be a fair amount.\n> I then unpack and \"git init\", I expect it to recognize it's a v2.6.24,\n> and I can thereafter use \"git fetch\" to fetch those commits after\n> v2.6.24 from git.kernel.org. Is this possible?\n\nI tried shallow clone (depth 1) with a fairly old linux-2.6 repo and\nthe pack was 68MB. A bit bigger than 40MB but still acceptable IMO.\nThe tarball+git-init way, I don't think it work. Maybe kernel.org\ncould release shallow git bundles in addition to tarballs so users\nlike you can download a bundle, make a repo from it and keep up with\n\"git fetch\".\n\n-- \nDuy\n"},{"id":"70535","messageId":"200803011641.49874.jnareb@gmail.com","threadId":"12378","inReplyTo":"f17812d70803010610o39cdf327x995c9e2e75a9edba@mail.gmail.com","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-01T15:41:49Z","receivedAt":"2008-03-01T15:41:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 1 Mar 2008, eric miao wrote:\n> On Fri, Feb 29, 2008 at 9:21 PM, Jakub Narebski wrote:\n\n[could you please remove irrelevant parts of the reply? TIA]\n\n>> There is so called \"shallow clone\" feature, which allows to clone only\n>> part of history. Currently it dupports only --depth, i.e. number of\n>> commits from tips; it could I guess support providing tag as\n>> delimiter. (You are welcome to implement it ;-).\n>>\n> \n> I haven't ever used the shallow clone, but it looks still a bit different\n> from what I thought originally, say, if I download linux-2.6.24.tar.bz2\n> from kernel.org, that's about 40MB and should be a fair amount.\n> I then unpack and \"git init\", I expect it to recognize it's a v2.6.24,\n> and I can thereafter use \"git fetch\" to fetch those commits after\n> v2.6.24 from git.kernel.org. Is this possible?\n\nNo, this doesn't work and couldn't work. The tarfile contains only\n_contents_ of the working directory, and perhaps commit-id, but it\ndoesn't contain even shred of history. Git has no information of\nwhere this content is in linux kernel git history.\n\nYou have to do \"git clone --depth=1 \"; surrently there is no\nway to specify \"git clone --from= \". I guess you can try\nto get info browsing gitweb, and fudge with grafts.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"70544","messageId":"8384AA89-4ECF-4BB8-8A3B-6A656F2D2903@orakel.ntnu.no","threadId":"12378","inReplyTo":"200803011641.49874.jnareb@gmail.com","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git@orakel.ntnu.no","sentAt":"2008-03-01T17:30:13Z","receivedAt":"2008-03-01T17:30:13Z","isPatch":false,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 1. mars. 2008, at 16.41, Jakub Narebski wrote:\n\n> On Sat, 1 Mar 2008, eric miao wrote:\n>\n>> I haven't ever used the shallow clone, but it looks still a bit \n>> different\n>> from what I thought originally, say, if I download \n>> linux-2.6.24.tar.bz2\n>> from kernel.org, that's about 40MB and should be a fair amount.\n>> I then unpack and \"git init\", I expect it to recognize it's a \n>> v2.6.24,\n>> and I can thereafter use \"git fetch\" to fetch those commits after\n>> v2.6.24 from git.kernel.org. Is this possible?\n>\n> No, this doesn't work and couldn't work. The tarfile contains only\n> _contents_ of the working directory, and perhaps commit-id, but it\n> doesn't contain even shred of history. Git has no information of\n> where this content is in linux kernel git history.\n\nOkay, as a git n00b I'm probably on completely the wrong track, but if \nyou made a git repository out of a kernel tarball (cd linux-2.6.24 && \ngit init && git add .) and then did a shallow fetch from kernel.org \ninto that repository, wouldn't the blobs you added get reused \n(assuming the tarball you downloaded was fairly recent), thus reducing \nthe amount of data fetch has to transfer?\n\nI'm sure you'd end up transferring more data than just a straight \nshallow clone, but it would be cool if that worked, and might even be \nuseful. I'm downloading 2.6.25-rc3 now to try it out :)\n\nEyvind Bernhardsen\n\n"},{"id":"70545","messageId":"200803011900.36723.jnareb@gmail.com","threadId":"12378","inReplyTo":"8384AA89-4ECF-4BB8-8A3B-6A656F2D2903@orakel.ntnu.no","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-01T18:00:35Z","receivedAt":"2008-03-01T18:00:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Eyvind Bernhardsen wrote:\n>\n> Okay, as a git n00b I'm probably on completely the wrong track, but if \n> you made a git repository out of a kernel tarball (cd linux-2.6.24 && \n> git init && git add .) and then did a shallow fetch from kernel.org \n> into that repository, wouldn't the blobs you added get reused \n> (assuming the tarball you downloaded was fairly recent), thus reducing \n> the amount of data fetch has to transfer?\n\nI think it wouldn't. If I understand it correctly, the fetching engine\ndeals only with commits. If you have commit, it assumes that you have \ntree, blobs, and ancestors. If you don't have commit, it assumes that \nyou don't have tree and blobs.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"70559","messageId":"20080301204352.GA862@old.davidb.org","threadId":"12378","inReplyTo":"8384AA89-4ECF-4BB8-8A3B-6A656F2D2903@orakel.ntnu.no","subject":"Re: Will git have a baseline feature or something alike?","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2008-03-01T20:43:52Z","receivedAt":"2008-03-01T20:43:52Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Sat, Mar 01, 2008 at 06:30:13PM +0100, Eyvind Bernhardsen wrote:\n\n> Okay, as a git n00b I'm probably on completely the wrong track, but if you \n> made a git repository out of a kernel tarball (cd linux-2.6.24 && git init \n> && git add .) and then did a shallow fetch from kernel.org into that \n> repository, wouldn't the blobs you added get reused (assuming the tarball \n> you downloaded was fairly recent), thus reducing the amount of data fetch \n> has to transfer?\n\nGit uses the commit history to determine what objects you might already\nhave. For normal use cases, this works quite well, however in this\ninstance it doesn't help at all. You'll ending up transferring everything,\neven for objects you already have. Git will detect that you already have\nthe object only after the transfer.\n\nThink about it, though. In order to do this generally, the client would\nhave to send the hash of every object it has. Perhaps this would be a\nuseful thing to do when git detects that there are no common commits, but\nit would only really help the case of pulling from multiple repos that\nmanage the same files with separate histories.\n\nThere are some cases where this happens, such as when changes go through\nanother revision control system, but probably not normal usage.\n\nDavid\n"},{"id":"70635","messageId":"20080302140446.GA8410@spearce.org","threadId":"12378","inReplyTo":"200803011900.36723.jnareb@gmail.com","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-02T14:04:46Z","receivedAt":"2008-03-02T14:04:46Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> Eyvind Bernhardsen wrote:\n> >\n> > Okay, as a git n00b I'm probably on completely the wrong track, but if \n> > you made a git repository out of a kernel tarball (cd linux-2.6.24 && \n> > git init && git add .) and then did a shallow fetch from kernel.org \n> > into that repository, wouldn't the blobs you added get reused \n> > (assuming the tarball you downloaded was fairly recent), thus reducing \n> > the amount of data fetch has to transfer?\n> \n> I think it wouldn't. If I understand it correctly, the fetching engine\n> deals only with commits. If you have commit, it assumes that you have \n> tree, blobs, and ancestors. If you don't have commit, it assumes that \n> you don't have tree and blobs.\n\nCorrect.\n\nI was thinking about this just yesterday. I think that if we\nembedded inside of a tarball created by git-archive the raw sources\nof all files, plus the commit SHA-1 and the raw body of that commit,\nit should be possible to convert that into a shallow clone.\n\nUnfortunately I think it is possible for git-archive to edit a file\nin-place during export, e.g. to edit an RPM spec file and insert\nthe revision. That would damage the tree, as the blobs would no\nlonger hash to the same value as they should be in that commit.\n\n-- \nShawn.\n"},{"id":"70688","messageId":"20080302193816.GA4276@efreet.light.src","threadId":"12378","inReplyTo":"47C95823.5090006@vilain.net","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-03-02T19:38:16Z","receivedAt":"2008-03-02T19:38:16Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, Mar 02, 2008 at 02:20:35 +1300, Sam Vilain wrote:\n> Jakub Narebski wrote:\n> > And last, KDE repos should most probably be split into submodules.\n> \n> Mmm. Everyone always says that; what it really needs I think is someone\n> to really take the conversion on board and come up with a workable plan\n> on this front. I think the counter-argument to this was \"but you always\n> want to have 70% of the repository checked out for development\".\n\nKDE should not be the case. The source for Debian packages is split in\nseveral independent source packages (which are compilable on their own). You\nshould rarely need more than 1 or 2 (the one you hack + base) checked out.\n\n> Counter-counter argument is \"yes but they don't always need to be deep\n> clones\". Anyway, it's not my baby, just thought I'd let you know about\n> it :-)\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"70701","messageId":"46a038f90803021329g29b19234wab6b626c9d47e7ab@mail.gmail.com","threadId":"12378","inReplyTo":"47C95823.5090006@vilain.net","subject":"Re: Will git have a baseline feature or something alike?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2008-03-02T21:29:37Z","receivedAt":"2008-03-02T21:29:37Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Sun, Mar 2, 2008 at 2:20 AM, Sam Vilain wrote:\n> > And last, KDE repos should most probably be split into submodules.\n>\n> Mmm. Everyone always says that; what it really needs I think is someone\n> to really take the conversion on board and come up with a workable plan\n> on this front. I think the counter-argument to this was \"but you always\n> want to have 70% of the repository checked out for development\".\n> Counter-counter argument is \"yes but they don't always need to be deep\n> clones\". Anyway, it's not my baby, just thought I'd let you know about\n> it :-)\n\nThat sounds a lot like the x.org submodule split. AFAIU, it did\ninvolve some relatively minor changes to configure/build scripts to\nhandle the submodules being built somewhere other than in a subdir of\nthe main project. Nothing earth shattering, just small changes to how\nthe build works, and I think after the initial shakeout everyone's\nhappy and the development pace is quite a bit faster & more\nadventurous.\n\nAll of this from bits I read in the x.org dev lists, and some\ndeveloper blogs - IANAX.OD\n\ncheers,\n\n\nm\n"}]}