{"thread":{"id":"7912","subject":"[PATCH 0/8] git-repack --max-pack-size","startedAt":"2007-04-30T23:16:07Z","lastAt":"2007-05-01T19:07:26Z","messageCount":11,"participants":["Dana How","Junio C Hamano","Shawn O. Pearce","Andy Parkins","Nicolas Pitre","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":8},"messages":[{"id":"40766","messageId":"463678B7.70409@gmail.com","threadId":"7912","inReplyTo":null,"subject":"[PATCH 0/8] git-repack --max-pack-size","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-04-30T23:16:07Z","receivedAt":"2007-04-30T23:16:07Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"\nThe three most common ways of making large packfiles\nare git-fast-import, the first git-repack, or git-repack -a.\nThe first already supports a \"--max-pack-size=N\" option,\nwhich limits the resulting packfiles to N megabytes.\nThis patchset adds the same option, with the same\nbehavior, to git-repack to handle the other two cases.\n\nThis iteration fixes miscellaneous issues discussed on the list\nand introduces no behavior not seen elsewhere in git.\nIt is based on \"next\" in order to incorporate Nicolas Pitre's work.\n"},{"id":"40781","messageId":"7v7irt9qm1.fsf@assigned-by-dhcp.cox.net","threadId":"7912","inReplyTo":"463678B7.70409@gmail.com","subject":"Re: [PATCH 0/8] git-repack --max-pack-size","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-01T03:20:38Z","receivedAt":"2007-05-01T03:20:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dana How writes:\n\n> It is based on \"next\" in order to incorporate Nicolas Pitre's work.\n\nHeh, since last night, 'master' and 'next' points at exactly the\nsame tree object, although their commit ancestry are vastly\ndifferent for obvious reasons.\n\nWhich leaves 'master' right now at v1.5.2-rc1 while 'next' at\nv1.5.2-rc1-687-gcb3892c; we might want to do something about\nthis apparent discrepancy.\n"},{"id":"40786","messageId":"20070501043753.GW5942@spearce.org","threadId":"7912","inReplyTo":"7v7irt9qm1.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/8] git-repack --max-pack-size","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-01T04:37:53Z","receivedAt":"2007-05-01T04:37:53Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Heh, since last night, 'master' and 'next' points at exactly the\n> same tree object, although their commit ancestry are vastly\n> different for obvious reasons.\n> \n> Which leaves 'master' right now at v1.5.2-rc1 while 'next' at\n> v1.5.2-rc1-687-gcb3892c; we might want to do something about\n> this apparent discrepancy.\n\nAre you considering rewinding next to master? I'm not sure how\nelse we could cancel out all of those merges and reverts of bad\nideas from next.\n\nOne option might be to teach git-describe to look for matching trees,\nand see if git-describe could match the tree that v1.5.2-rc1 points\nat with the tree that cb3892c points and, and just call the latter\nthe former... But that sounds a little risky to me in some projects,\nI'm not convinced that is always the right way to describe a history.\n\n-- \nShawn.\n"},{"id":"40803","messageId":"200705010926.35265.andyparkins@gmail.com","threadId":"7912","inReplyTo":"7v7irt9qm1.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/8] git-repack --max-pack-size","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-01T08:26:33Z","receivedAt":"2007-05-01T08:26:33Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 May 01, Junio C Hamano wrote:\n\n> Which leaves 'master' right now at v1.5.2-rc1 while 'next' at\n> v1.5.2-rc1-687-gcb3892c; we might want to do something about\n> this apparent discrepancy.\n\nIt's perfect - I'd say that it's exactly right.\n\ngit-describe is for making unique - human readable names for points in \nhistory, not for describing the tree. It makes no difference that A and B \nhave the same tree, they are different points.\n\nI've always thought of git-describe as being a way of mapping a commit hash to \na nicer looking name. If A and B are different commits then they should have \ndifferent names.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40806","messageId":"7virbc7vue.fsf@assigned-by-dhcp.cox.net","threadId":"7912","inReplyTo":"200705010926.35265.andyparkins@gmail.com","subject":"Re: [PATCH 0/8] git-repack --max-pack-size","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-01T09:10:33Z","receivedAt":"2007-05-01T09:10:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Tuesday 2007 May 01, Junio C Hamano wrote:\n>\n>> Which leaves 'master' right now at v1.5.2-rc1 while 'next' at\n>> v1.5.2-rc1-687-gcb3892c; we might want to do something about\n>> this apparent discrepancy.\n>\n> It's perfect - I'd say that it's exactly right.\n>\n> git-describe is for making unique - human readable names for points in \n> history, not for describing the tree. It makes no difference that A and B \n> have the same tree, they are different points.\n>\n> I've always thought of git-describe as being a way of mapping a commit hash to \n> a nicer looking name. If A and B are different commits then they should have \n> different names.\n\nAlthough 'next' and 'master' have vastly different histories\nbehind them, among 685 commits between master and next, only 27\nare non-merges, among which 20 are \"real\" commits that tried to\nadvance various topics that failed, and 7 are reverts against\nthese 20 commits [*1*].\n\nEven though hstory of failed attempts (why they initially seemed\ngood ideas, how they tried to solve problems, and why they\nturned out not to be so good ideas in the end) are interesting,\nif we ignore the failed attempts, iow, if we view the history\nfrom the point of view of \"surviving features\", the development\nhistory of 'next' and 'master' are moral equivalents. Yes, most\nof them were merged way earlier in 'next' than 'master', many of\nthem were merged in multiple steps of two and three to 'next'\nand then finally merged to 'master' with a single merge, but the\nchanges did hit both 'master' and 'next' (obviously, that is why\nwe ended up with the same trees).\n\nSo the equivalence of 'master' and 'next' tonight is not quite\nthe same as equating two random commits that happen to have the\nsame tree. v1.5.2-rc1 and v1.5.2-rc1-687-gcb3892c should\nnaturally have the same tree because they share conceptually the\nsame history.\n\nBut I was not talking about changing describe output because of\nthe above argument. What I was wondering was that it might be a\ngood idea to loosen the promise of never rewinding 'next'. It\nmight be easier to view the history of 'next' during development\nfor each cycle, if it started afresh after a feature release.\n\nSince now we are in a stabilization freeze, I expect that\n'master' and 'next' will always have identical trees until\nv1.5.2 final. We _could_ declare now that 'next' will be reset\nto 'master' when v1.5.2 happens, and people who forked from\n'next' to do their own customization can rebase any time that is\nconvenient for them between tonight and v1.5.2 final.\n\nI was not sure if that is even a good idea, and I am now\ninclined to think that keeping the failed attempt history is\nprobably better than potentially causing confusion to people who\nfollow 'next'. But it _is_ a possibility to reset 'next' to\n'master'.\n\n\n[Footnote]\n\n*1* Some topics I did not use \"git revert\" to revert them\none-by-one; instead, I reverted a whole topic with one commit.\n"},{"id":"40810","messageId":"200705011037.03213.andyparkins@gmail.com","threadId":"7912","inReplyTo":"7virbc7vue.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/8] git-repack --max-pack-size","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-05-01T09:36:57Z","receivedAt":"2007-05-01T09:36:57Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 May 01, Junio C Hamano wrote:\n\n> But I was not talking about changing describe output because of\n> the above argument. What I was wondering was that it might be a\n> good idea to loosen the promise of never rewinding 'next'. It\n> might be easier to view the history of 'next' during development\n> for each cycle, if it started afresh after a feature release.\n\nThis is an interesting philosophy-of-version-control question. If two \nidentical trees fall in the forest and there is no one there to diff them, \nwas a release made? :-)\n\nIt's been my experience that failed attempts and dead-end branches are often \nof equal value to the successful branches. It's very handy when someone \nasks \"why can't we do it like this\", to be able to answer \"look at revision \nxyz onwards\". Even just for your own reference, I've often looked back on \nabandoned paths and thought \"that wasn't as bad as I thought, I just need to \nfix it here and here\" - if I'd discarded that work it would be gone forever.\n\nIt's certainly true in academia, a large part of my doctoral thesis was \nabout \"things that don't work\" :-) Documenting failure is as important as \ndocumenting success.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"40820","messageId":"alpine.LFD.0.98.0705011044210.6574@xanadu.home","threadId":"7912","inReplyTo":"7virbc7vue.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/8] git-repack --max-pack-size","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-05-01T14:46:20Z","receivedAt":"2007-05-01T14:46:20Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 1 May 2007, Junio C Hamano wrote:\n\n> I was not sure if that is even a good idea, and I am now\n> inclined to think that keeping the failed attempt history is\n> probably better than potentially causing confusion to people who\n> follow 'next'. But it _is_ a possibility to reset 'next' to\n> 'master'.\n\nAnd what is the advantage of doing that, exactly?\n\n\nNicolas\n"},{"id":"40835","messageId":"7vps5k5uzt.fsf@assigned-by-dhcp.cox.net","threadId":"7912","inReplyTo":"alpine.LFD.0.98.0705011044210.6574@xanadu.home","subject":"Re: [PATCH 0/8] git-repack --max-pack-size","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-01T17:11:50Z","receivedAt":"2007-05-01T17:11:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Tue, 1 May 2007, Junio C Hamano wrote:\n>\n>> I was not sure if that is even a good idea, and I am now\n>> inclined to think that keeping the failed attempt history is\n>> probably better than potentially causing confusion to people who\n>> follow 'next'. But it _is_ a possibility to reset 'next' to\n>> 'master'.\n>\n> And what is the advantage of doing that, exactly?\n\nNot much and that is why I am not sure if that is a good idea,\nbut one thing is:\n\n\t$ git log master..next\n\t$ git log --no-merges master..next\n\nwould start showing what are still pending in next without\nnoise.\n\nWith the current 'next', the output of the former is almost\nuseless, and the latter is useful only until 'next' starts\ndiverging again from the master and if you are interested in\nwhat will never merged to 'master'. Once 'next' starts growing\nagain, you will get mixture of what's cooking and what's killed;\nthe output from the latter would become useless again.\n"},{"id":"40836","messageId":"alpine.LFD.0.98.0705011315180.6574@xanadu.home","threadId":"7912","inReplyTo":"7vps5k5uzt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/8] git-repack --max-pack-size","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-05-01T17:17:20Z","receivedAt":"2007-05-01T17:17:20Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 1 May 2007, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > On Tue, 1 May 2007, Junio C Hamano wrote:\n> >\n> >> I was not sure if that is even a good idea, and I am now\n> >> inclined to think that keeping the failed attempt history is\n> >> probably better than potentially causing confusion to people who\n> >> follow 'next'. But it _is_ a possibility to reset 'next' to\n> >> 'master'.\n> >\n> > And what is the advantage of doing that, exactly?\n> \n> Not much and that is why I am not sure if that is a good idea,\n> but one thing is:\n> \n> \t$ git log master..next\n> \t$ git log --no-merges master..next\n> \n> would start showing what are still pending in next without\n> noise.\n\nIf you do so, then please tag the branch before resetting it. I think \nit contains valuable data that would get lost otherwise.\n\n\nNicolas\n"},{"id":"40838","messageId":"Pine.LNX.4.64.0705011939590.4010@racer.site","threadId":"7912","inReplyTo":"7vps5k5uzt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/8] git-repack --max-pack-size","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-01T17:42:50Z","receivedAt":"2007-05-01T17:42:50Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 1 May 2007, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > On Tue, 1 May 2007, Junio C Hamano wrote:\n> >\n> >> I was not sure if that is even a good idea, and I am now\n> >> inclined to think that keeping the failed attempt history is\n> >> probably better than potentially causing confusion to people who\n> >> follow 'next'. But it _is_ a possibility to reset 'next' to\n> >> 'master'.\n> >\n> > And what is the advantage of doing that, exactly?\n> \n> Not much and that is why I am not sure if that is a good idea,\n> but one thing is:\n> \n> \t$ git log master..next\n> \t$ git log --no-merges master..next\n> \n> would start showing what are still pending in next without\n> noise.\n\nOf course, you could graft a fake relationship there. Something like\n\necho $(git rev-parse master master^ next) >> .git/info/grafts\n\nshould do. And you can do it _locally_, since all you care about is the \nhigher-level relationship that _you_ know about. And this is the way to \nteach Git about it.\n\nCiao,\nDscho\n"},{"id":"40848","messageId":"7vlkg85pn5.fsf@assigned-by-dhcp.cox.net","threadId":"7912","inReplyTo":"Pine.LNX.4.64.0705011939590.4010@racer.site","subject":"Re: [PATCH 0/8] git-repack --max-pack-size","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-01T19:07:26Z","receivedAt":"2007-05-01T19:07:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Tue, 1 May 2007, Junio C Hamano wrote:\n>\n>> Nicolas Pitre writes:\n>> \n>> > On Tue, 1 May 2007, Junio C Hamano wrote:\n>> >\n>> >> I was not sure if that is even a good idea, and I am now\n>> >> inclined to think that keeping the failed attempt history is\n>> >> probably better than potentially causing confusion to people who\n>> >> follow 'next'. But it _is_ a possibility to reset 'next' to\n>> >> 'master'.\n>> >\n>> > And what is the advantage of doing that, exactly?\n>> \n>> Not much and that is why I am not sure if that is a good idea,\n>> but one thing is:\n>> \n>> \t$ git log master..next\n>> \t$ git log --no-merges master..next\n>> \n>> would start showing what are still pending in next without\n>> noise.\n>\n> Of course, you could graft a fake relationship there. Something like\n>\n> echo $(git rev-parse master master^ next) >> .git/info/grafts\n>\n> should do. And you can do it _locally_, since all you care about is the \n> higher-level relationship that _you_ know about. And this is the way to \n> teach Git about it.\n\nIn case you did not get it, making the above usable is not about _me_.\n"}]}