{"thread":{"id":"3079","subject":"dangling commits","startedAt":"2006-01-15T20:56:13Z","lastAt":"2006-01-16T12:40:20Z","messageCount":15,"participants":["Nick Williams","Andreas Ericsson","Junio C Hamano","Wolfgang Denk","Marco Roeland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"14695","messageId":"43CAB6ED.3010703@op5.se","threadId":"3079","inReplyTo":"dqebk9$75f$1@sea.gmane.org","subject":"Re: dangling commits","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-01-15T20:56:13Z","receivedAt":"2006-01-15T20:56:13Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Nick Williams wrote:\n> Hi, after cloning the git repo with\n> \n> cg-clone http://www.kernel.org/pub/scm/git/git.git git\n> \n> and then doing\n> \n> git-fsck-objects --full\n> \n> I get the following\n> \n> dangling commit 42db15448ea3c21ae458d5ea873157449042c07c\n> dangling commit 4d04a4022e7f9f3ada3a64e2010ce65e1fcc5c64\n> dangling commit a773f5bda1835d739ee7209589e137ddd7199142\n> dangling commit ceb90a511add3b362f1384aa6ea35370d12db315\n> \n> However if I do cg-clone git://git.kernel.org/pub/scm/git/git.git\n> there's no output from git-fsck --full\n> \n> git version = 1.1.GIT\n> cogito version = cogito-0.17pre.GIT\n> \n> did I do something wrong (again)?\n> \n\nNopes. One clones over http, so you'll get all objects in the object \ndatabase. The other clones over the far more clever git protocol which \ncalculates which objects you need. Obviously you don't need dangling \ncommits (and their related blobs), so there will be no such items.\n\nThat there are on kernel.org at all is because Junio does rebases of the \npu branch and then pushes them out, which means that the objects from \nthe last rebase of that branch are left dangling.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"14693","messageId":"dqebk9$75f$1@sea.gmane.org","threadId":"3079","inReplyTo":null,"subject":"dangling commits","fromName":"Nick Williams","fromEmail":"njw@jarb.freeserve.co.uk","sentAt":"2006-01-15T21:05:54Z","receivedAt":"2006-01-15T21:05:54Z","isPatch":false,"sender":{"key":"njw@jarb.freeserve.co.uk","avatar":null},"body":"Hi, after cloning the git repo with\n\ncg-clone http://www.kernel.org/pub/scm/git/git.git git\n\nand then doing\n\ngit-fsck-objects --full\n\nI get the following\n\ndangling commit 42db15448ea3c21ae458d5ea873157449042c07c\ndangling commit 4d04a4022e7f9f3ada3a64e2010ce65e1fcc5c64\ndangling commit a773f5bda1835d739ee7209589e137ddd7199142\ndangling commit ceb90a511add3b362f1384aa6ea35370d12db315\n\nHowever if I do cg-clone git://git.kernel.org/pub/scm/git/git.git\nthere's no output from git-fsck --full\n\ngit version = 1.1.GIT\ncogito version = cogito-0.17pre.GIT\n\ndid I do something wrong (again)?\n"},{"id":"14698","messageId":"7vslrp2nw0.fsf@assigned-by-dhcp.cox.net","threadId":"3079","inReplyTo":"dqedel$d0q$1@sea.gmane.org","subject":"Re: dangling commits","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-15T21:15:59Z","receivedAt":"2006-01-15T21:15:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nick Williams writes:\n\n> Andreas Ericsson wrote:\n>..\n>> Nopes. One clones over http, so you'll get all objects in the object\n>> database. The other clones over the far more clever git protocol\n>> which calculates which objects you need. Obviously you don't need\n>> dangling commits (and their related blobs), so there will be no such\n>> items.\n\nNote that only because that is these dangling objects are packed\nin the past, and when fetching over http, packs are fetched as a\nwhole.\n\n> So, is there any advantage of using http? Seems like git:// makes more\n> sense.\n\nAs long as you can go native git:// protocol, I do not see much\nreason to use http:// commit walkers. OTOH, if you are\nfirewalled and your sysadmins do not let you pass 9418/tcp\noutgoing, HTTP might be your only choice.\n"},{"id":"14696","messageId":"dqedel$d0q$1@sea.gmane.org","threadId":"3079","inReplyTo":"43CAB6ED.3010703@op5.se","subject":"Re: dangling commits","fromName":"Nick Williams","fromEmail":"njw@jarb.freeserve.co.uk","sentAt":"2006-01-15T21:37:00Z","receivedAt":"2006-01-15T21:37:00Z","isPatch":false,"sender":{"key":"njw@jarb.freeserve.co.uk","avatar":null},"body":"Andreas Ericsson wrote:\n> Nick Williams wrote:\n> \n>> Hi, after cloning the git repo with\n>>\n>> cg-clone http://www.kernel.org/pub/scm/git/git.git git\n>>\n>> and then doing\n>>\n>> git-fsck-objects --full\n>>\n>> I get the following\n>>\n>> dangling commit 42db15448ea3c21ae458d5ea873157449042c07c\n>> dangling commit 4d04a4022e7f9f3ada3a64e2010ce65e1fcc5c64\n>> dangling commit a773f5bda1835d739ee7209589e137ddd7199142\n>> dangling commit ceb90a511add3b362f1384aa6ea35370d12db315\n>>\n>> However if I do cg-clone git://git.kernel.org/pub/scm/git/git.git\n>> there's no output from git-fsck --full\n>>\n>> git version = 1.1.GIT\n>> cogito version = cogito-0.17pre.GIT\n>>\n>> did I do something wrong (again)?\n>>\n> \n> Nopes. One clones over http, so you'll get all objects in the object \n> database. The other clones over the far more clever git protocol which \n> calculates which objects you need. Obviously you don't need dangling \n> commits (and their related blobs), so there will be no such items.\n\nOK, that makes sense - thanks for the explanation.\n\n> \n> That there are on kernel.org at all is because Junio does rebases of the \n> pu branch and then pushes them out, which means that the objects from \n> the last rebase of that branch are left dangling.\n> \n\nSo, is there any advantage of using http? Seems like git:// makes more \nsense.\n"},{"id":"14699","messageId":"20060115221108.3ED2E352659@atlas.denx.de","threadId":"3079","inReplyTo":"7vslrp2nw0.fsf@assigned-by-dhcp.cox.net","subject":"Re: dangling commits","fromName":"Wolfgang Denk","fromEmail":"wd@denx.de","sentAt":"2006-01-15T22:11:08Z","receivedAt":"2006-01-15T22:11:08Z","isPatch":false,"sender":{"key":"wd@denx.de","avatar":null},"body":"In message <7vslrp2nw0.fsf@assigned-by-dhcp.cox.net> you wrote:\n>\n> Note that only because that is these dangling objects are packed\n> in the past, and when fetching over http, packs are fetched as a\n> whole.\n\nIs ther eany way to clean up such a situation and really get rid of\nthe dangling commits? I understand that I'd first need some way to\n\"unpack\" the packs, but how to do this? \n\nBest regards,\n\nWolfgang Denk\n\n-- \nSoftware Engineering: Embedded and Realtime Systems, Embedded Linux\nPhone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de\nHeavier than air flying machines are impossible.\n -- Lord Kelvin, President, Royal Society, c. 1895\n"},{"id":"14700","messageId":"7v8xth14pg.fsf@assigned-by-dhcp.cox.net","threadId":"3079","inReplyTo":"20060115221108.3ED2E352659@atlas.denx.de","subject":"Re: dangling commits","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-15T22:55:39Z","receivedAt":"2006-01-15T22:55:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wolfgang Denk writes:\n\n> Is ther eany way to clean up such a situation and really get rid of\n> the dangling commits? I understand that I'd first need some way to\n> \"unpack\" the packs, but how to do this? \n\nThe easiest is to repack into a single big ball of wax:\n\n\t$ git repack -a -d\n\nIf you know the pack the stale object is in, you can move it out\nof objects/pack/ and repack only that one.\n\n\t$ mv .git/objects/packs/pack-$badone.{idx,pack} .\n\t$ git unpack-objects Is ther eany way to clean up such a situation and really get rid of\n> the dangling commits? I understand that I'd first need some way to\n> \"unpack\" the packs, but how to do this? \n\nNote that apart from the disk space they use up, dangling commits don't\ndo any harm.\n\nHowever you can easily get rid of them by using \"git prune\".\n\nAs far as I know although packs are used in transferring the commits to\nyour local repository they are stored there as separate objects, so you\ncertainly don't have to unpack things yourself for using \"git prune\".\nGit is quite smart, fast and safe on its own I find each time! It really\nis a wonderful tool by giving you every possibility to work with it\nwithout inflicting policy on you.\n\nIf wanted you can use \"git repack -a -d\" followed by \"git prune-packed\"\nto create a tight packed repository (all commits and blobs in one pack)\nbut there is no specific need to.\n-- \nMarco Roeland\n"},{"id":"14719","messageId":"7vr778wmj3.fsf@assigned-by-dhcp.cox.net","threadId":"3079","inReplyTo":"20060116085238.GA3768@fiberbit.xs4all.nl","subject":"Re: dangling commits","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-16T09:27:12Z","receivedAt":"2006-01-16T09:27:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marco Roeland writes:\n\n> As far as I know although packs are used in transferring the commits to\n> your local repository they are stored there as separate objects,...\n\nThat is true only when you are using git native protocols\n(i.e. git:// and git over ssh). Some people pull over dumb\ntransport (http -- some others still use rsync which is even\ndumber and has serious limitations), and when you need objects\nthat are contained in a pack at the upstream, the packfile is\ndownloaded as a whole, and it is left packed on your end.\n\nEven when you use git native protocol, the objects the initial\nclone gives you are kept packed, so when I rewind and rebuild\n\"pu\" to make some of these objects orphaned, they will stay in\nthe pack the initial clone gave you. Unpack+repack is needed to\nget rid of them.\n\nAs you said, they should not hurt much in practice, though.\n"},{"id":"14720","messageId":"20060116093249.8F939353A3F@atlas.denx.de","threadId":"3079","inReplyTo":"20060116085238.GA3768@fiberbit.xs4all.nl","subject":"Re: dangling commits","fromName":"Wolfgang Denk","fromEmail":"wd@denx.de","sentAt":"2006-01-16T09:32:49Z","receivedAt":"2006-01-16T09:32:49Z","isPatch":false,"sender":{"key":"wd@denx.de","avatar":null},"body":"In message <20060116085238.GA3768@fiberbit.xs4all.nl> you wrote:\n> \n> Note that apart from the disk space they use up, dangling commits don't\n> do any harm.\n\nI like to have my repository \"clean\" so there are no warnings\nnormally from git-fsck-objects - if you get used to expect some\n\"harmless\" messages you might easily miss a critical error.\n\n> However you can easily get rid of them by using \"git prune\".\n\nTried this, didn't work.\n\n> As far as I know although packs are used in transferring the commits to\n> your local repository they are stored there as separate objects, so you\n\nUmmm... please have a look at the .git/objects/pack/ directory for\nexample in your Linux repository.\n\nBest regards,\n\nWolfgang Denk\n\n-- \nSoftware Engineering: Embedded and Realtime Systems, Embedded Linux\nPhone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de\nIt seems intuitively obvious to me, which means that it might be\nwrong. -- Chris Torek\n"},{"id":"14721","messageId":"20060116100814.GA5196@fiberbit.xs4all.nl","threadId":"3079","inReplyTo":"20060116093249.8F939353A3F@atlas.denx.de","subject":"Re: dangling commits","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-01-16T10:08:14Z","receivedAt":"2006-01-16T10:08:14Z","isPatch":false,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"On Monday January 16th 2006 Wolfgang Denk wrote:\n\n> I like to have my repository \"clean\" so there are no warnings\n> normally from git-fsck-objects - if you get used to expect some\n> \"harmless\" messages you might easily miss a critical error.\n\nThat's right, yes.\n\n> > However you can easily get rid of them by using \"git prune\".\n> \n> Tried this, didn't work.\n\nOk, didn't know that it didn't prune directly from packs. I should have\nrealised that it only can do so efficiently by repacking I suppose.\n\n> Ummm... please have a look at the .git/objects/pack/ directory for\n> example in your Linux repository.\n\nI did as a matter of fact, but I use \"git\" as protocol and also\nregularly \"repack\" the repository, when I'm not using the machine for\na while, to make 'gitk' and 'qgit' work faster. It is less apparent\nthen! Thanks very much for clearing up my knowledge. It only shows the\npower of git that even ignorant gits like myself still find it useful\nand productive. There's just enough rope to wiggle yourself out of\nprecarious situations but fortunately most of the time not enough to\nhang yourself.\n-- \nMarco Roeland\n"},{"id":"14723","messageId":"20060116101722.GB5196@fiberbit.xs4all.nl","threadId":"3079","inReplyTo":"7vr778wmj3.fsf@assigned-by-dhcp.cox.net","subject":"Re: dangling commits","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-01-16T10:17:22Z","receivedAt":"2006-01-16T10:17:22Z","isPatch":false,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"On Monday January 16th Junio C Hamano wrote:\n\n> Even when you use git native protocol, the objects the initial\n> clone gives you are kept packed, so when I rewind and rebuild\n> \"pu\" to make some of these objects orphaned, they will stay in\n> the pack the initial clone gave you. Unpack+repack is needed to\n> get rid of them.\n\nThanks very much for explaining. It makes sense now.\n\nDoes it bring many advantages for you to keep rebasing \"pu\"? I started\nout following that branch long ago (well in git reckoning anyway) but\ngot very scared each time I got a bunch of \"errors\" on that one. I even\nrecloned a couple of times to get it \"clean\" again, until I understood\nfrom the mailing-list that the rebasing was the cause, not something I\ndid. I since removed it from the \"Pull\" list, but understand that \"+pu\"\nshould do the trick. I'll retry using it one of these days.\n-- \nMarco Roeland\n"},{"id":"14724","messageId":"43CB753D.2030706@op5.se","threadId":"3079","inReplyTo":"20060116101722.GB5196@fiberbit.xs4all.nl","subject":"Re: dangling commits","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-01-16T10:28:13Z","receivedAt":"2006-01-16T10:28:13Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Marco Roeland wrote:\n> On Monday January 16th Junio C Hamano wrote:\n> \n> \n>>Even when you use git native protocol, the objects the initial\n>>clone gives you are kept packed, so when I rewind and rebuild\n>>\"pu\" to make some of these objects orphaned, they will stay in\n>>the pack the initial clone gave you. Unpack+repack is needed to\n>>get rid of them.\n> \n> \n> Thanks very much for explaining. It makes sense now.\n> \n> Does it bring many advantages for you to keep rebasing \"pu\"?\n\n\nSince \"pu\" = \"proposed updates\" it only makes sense to keep it on top of \nthe current master, otherwise the effort required for anyone to test it \nin conjunction with the latest master branch would simply be too great.\n\n\n> I started\n> out following that branch long ago (well in git reckoning anyway) but\n> got very scared each time I got a bunch of \"errors\" on that one.\n> I since removed it from the \"Pull\" list, but understand that \"+pu\"\n> should do the trick. I'll retry using it one of these days.\n\n\nIt does. I also remember seeing lots of errors on that one when I first \nstarted with git (around 0.99b), but that was fixed quite some time ago.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"14727","messageId":"20060116113332.GA5356@fiberbit.xs4all.nl","threadId":"3079","inReplyTo":"43CB753D.2030706@op5.se","subject":"Re: dangling commits","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-01-16T11:33:32Z","receivedAt":"2006-01-16T11:33:32Z","isPatch":false,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"On Monday January 16th 2006 Andreas Ericsson wrote:\n\n> Since \"pu\" = \"proposed updates\" it only makes sense to keep it on top of \n> the current master, otherwise the effort required for anyone to test it \n> in conjunction with the latest master branch would simply be too great.\n\nCertainly. And it probably is a good testbed for testing the rebasing\nroutines as well.\n\nBut couldn't (in theory) the new \"rebased\" versions of blobs in the \"pu\"\nbranch be first committed as the old not yet rebased version and then\nas the new version. Not the fact that the blobs in \"pu\" are constantly\nbased on the latest master was the problem if I recollect, but the fact\nthat blobs sometimes disappeared. In comparing this with Linus' recent\nexplanation how git-bisect works in terms of light cones this might be\nunderstood as the inherent problems with tachyons I think...\n\nAnyway this is now solved I understand. Thanks.\n\n> >I since removed it from the \"Pull\" list, but understand that \"+pu\"\n> >should do the trick. I'll retry using it one of these days.\n> \n> It does. I also remember seeing lots of errors on that one when I first \n> started with git (around 0.99b), but that was fixed quite some time ago.\n\nOk, thanks very much for explaining.\n-- \nMarco Roeland\n"},{"id":"14728","messageId":"43CB8BFC.8050900@op5.se","threadId":"3079","inReplyTo":"20060116113332.GA5356@fiberbit.xs4all.nl","subject":"Re: dangling commits","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-01-16T12:05:16Z","receivedAt":"2006-01-16T12:05:16Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Marco Roeland wrote:\n> On Monday January 16th 2006 Andreas Ericsson wrote:\n> \n> \n>>Since \"pu\" = \"proposed updates\" it only makes sense to keep it on top of \n>>the current master, otherwise the effort required for anyone to test it \n>>in conjunction with the latest master branch would simply be too great.\n> \n> \n> But couldn't (in theory) the new \"rebased\" versions of blobs in the \"pu\"\n> branch be first committed as the old not yet rebased version and then\n> as the new version.\n\n\nThe blobs are immutable and never change for a rebase, unless the \nfile(s) it applies to is changed in master as well. It's the commits \nthat do because they get new parents.\n\nRemember that the blob object is just the (deltified?) file that's the \nresult of the commit operation. The commit object is an object in its \nown rights, holding author info and commit-time and such. Do\n\n\t$ git cat-file commit HEAD\n\nand you'll see what a commit-object looks like.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"14729","messageId":"20060116124020.GB5356@fiberbit.xs4all.nl","threadId":"3079","inReplyTo":"43CB8BFC.8050900@op5.se","subject":"Re: dangling commits","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-01-16T12:40:20Z","receivedAt":"2006-01-16T12:40:20Z","isPatch":false,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"On Monday January 16th 2006 Andreas Ericsson wrote:\n\n> The blobs are immutable and never change for a rebase, unless the \n> file(s) it applies to is changed in master as well. It's the commits \n> that do because they get new parents.\n\nAh, I need to rebase my mental picture of what a \"rebase\" is. ;-) And\nthe fact that each commit _does_ have sort of a blob (well in my mind I\ncalled it so, the file under .git/objects, although its proper name is\nindeed \"commit\") in the repository doesn't make it any easier!\n\nCurrent documentation about git-rebase(1) is technically correct of\ncourse then: \"rebases local commits to the new head of the upstream\ntree\" but rather sparse for the less initiated. In Dutch we have an\nexpression for this, to \"not be able to see the wood because of the\ntrees\", which is rather appropriate here. Perhaps we can introduce\n\"liana\" as an alternative for commit.\n\n\n\nSeriously, yours and other peoples comments make the picture much\nclearer to me and help out enormously to me and hopefully other lurkers\nin working with git and more advanced SCM in general. Thanks,\n-- \nMarco Roeland\n"}]}