{"thread":{"id":"21889","subject":"help: bisect single file from repos","startedAt":"2009-12-07T12:59:56Z","lastAt":"2009-12-09T12:12:52Z","messageCount":10,"participants":["walter harms","Michael J Gruber","Christian Couder","Junio C Hamano","SZEDER Gábor","Nanako Shiraishi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"129422","messageId":"4B1CFC4C.6090406@bfs.de","threadId":"21889","inReplyTo":null,"subject":"help: bisect single file from repos","fromName":"walter harms","fromEmail":"wharms@bfs.de","sentAt":"2009-12-07T12:59:56Z","receivedAt":"2009-12-07T12:59:56Z","isPatch":false,"sender":{"key":"wharms@bfs.de","avatar":null},"body":"Hi list,\ni am new to git (using: git version 1.6.0.2).\n\nI would like to bisect a single file but i have only commit id, no tags.\n\nBackground:\nI have a copy of the busybox git repos, and i know there is (perhaps) a bug\nin ash.c.\n\nhow can i do that ?\n\nre,\n wh\n"},{"id":"129424","messageId":"4B1D1A5A.9060004@drmicha.warpmail.net","threadId":"21889","inReplyTo":"4B1CFC4C.6090406@bfs.de","subject":"Re: help: bisect single file from repos","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-12-07T15:08:10Z","receivedAt":"2009-12-07T15:08:10Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"walter harms venit, vidit, dixit 07.12.2009 13:59:\n> Hi list,\n> i am new to git (using: git version 1.6.0.2).\n\nthough your git is not that new ;)\n\n> I would like to bisect a single file but i have only commit id, no tags.\n> \n> Background:\n> I have a copy of the busybox git repos, and i know there is (perhaps) a bug\n> in ash.c.\n> \n> how can i do that ?\n\nYou don't need any tags for bisecting. The man page of git-bisect has\nseveral examples on how to use it. Do you have a test script which\nexposes the bug?\n\nMichael\n"},{"id":"129428","messageId":"4B1D27B6.7010900@bfs.de","threadId":"21889","inReplyTo":"4B1D1A5A.9060004@drmicha.warpmail.net","subject":"Re: help: bisect single file from repos","fromName":"walter harms","fromEmail":"wharms@bfs.de","sentAt":"2009-12-07T16:05:10Z","receivedAt":"2009-12-07T16:05:10Z","isPatch":false,"sender":{"key":"wharms@bfs.de","avatar":null},"body":"\n\nMichael J Gruber schrieb:\n> walter harms venit, vidit, dixit 07.12.2009 13:59:\n>> Hi list,\n>> i am new to git (using: git version 1.6.0.2).\n> \n> though your git is not that new ;)\n> \n>> I would like to bisect a single file but i have only commit id, no tags.\n>>\n>> Background:\n>> I have a copy of the busybox git repos, and i know there is (perhaps) a bug\n>> in ash.c.\n>>\n>> how can i do that ?\n> \n> You don't need any tags for bisecting. The man page of git-bisect has\n> several examples on how to use it. Do you have a test script which\n> exposes the bug?\n> \n\nunfortunately no, the error shows up very nicely when booting my embdedded system\nbut not else (this is the reason i would to bisect that file only and not busybox\ncompletely). And from the man pages i got the impression that it is only possible the\nstart with a tag.\n\ni already had the hint that i need to do:\ngit bisect start bad_commit_id good_commit_id -- ash.c\n\nNtl, there is one more question, how can i make sure that\ni use the right version ? first i toughed that cherry-pick is the right idea\nbut it seems that that will apply onyl certain patches ?\n\nre,\n wh\n"},{"id":"129508","messageId":"200912080917.17220.chriscool@tuxfamily.org","threadId":"21889","inReplyTo":"4B1D27B6.7010900@bfs.de","subject":"Re: help: bisect single file from repos","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-12-08T08:17:17Z","receivedAt":"2009-12-08T08:17:17Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn lundi 07 décembre 2009, walter harms wrote:\n> Michael J Gruber schrieb:\n> > walter harms venit, vidit, dixit 07.12.2009 13:59:\n> >> Hi list,\n> >> i am new to git (using: git version 1.6.0.2).\n> >\n> > though your git is not that new ;)\n> >\n> >> I would like to bisect a single file but i have only commit id, no\n> >> tags.\n> >>\n> >> Background:\n> >> I have a copy of the busybox git repos, and i know there is (perhaps)\n> >> a bug in ash.c.\n> >>\n> >> how can i do that ?\n> >\n> > You don't need any tags for bisecting. The man page of git-bisect has\n> > several examples on how to use it. Do you have a test script which\n> > exposes the bug?\n>\n> unfortunately no, the error shows up very nicely when booting my\n> embdedded system but not else (this is the reason i would to bisect that\n> file only and not busybox completely). And from the man pages i got the\n> impression that it is only possible the start with a tag.\n\nThe man page says:\n\ngit bisect start [ [...]] [--] [...]\n\nand then:\n\n\"This command uses git rev-list --bisect to help drive the binary search \nprocess to find which change introduced a bug, given an old \"good\" commit \nobject name and a later \"bad\" commit object name.\"\n\n> i already had the hint that i need to do:\n> git bisect start bad_commit_id good_commit_id -- ash.c\n\nSo did you try that?\n\n> Ntl, there is one more question, how can i make sure that\n> i use the right version ?\n\nIf you mean the right git version, then I think any 1.6.X should be enough.\n\n> first i toughed that cherry-pick is the right \n> idea but it seems that that will apply onyl certain patches ?\n\nIf you want to find the commit that introduced a bug, then you should not \nneed cherry-pick.\n\nRegards,\nChristian.\n"},{"id":"129534","messageId":"4B1E5796.2090201@bfs.de","threadId":"21889","inReplyTo":"200912080917.17220.chriscool@tuxfamily.org","subject":"Re: help: bisect single file from repos","fromName":"walter harms","fromEmail":"wharms@bfs.de","sentAt":"2009-12-08T13:41:42Z","receivedAt":"2009-12-08T13:41:42Z","isPatch":false,"sender":{"key":"wharms@bfs.de","avatar":null},"body":"\n\nChristian Couder schrieb:\n> Hi,\n> \n> On lundi 07 décembre 2009, walter harms wrote:\n>> Michael J Gruber schrieb:\n>>> walter harms venit, vidit, dixit 07.12.2009 13:59:\n>>>> Hi list,\n>>>> i am new to git (using: git version 1.6.0.2).\n>>> though your git is not that new ;)\n>>>\n>>>> I would like to bisect a single file but i have only commit id, no\n>>>> tags.\n>>>>\n>>>> Background:\n>>>> I have a copy of the busybox git repos, and i know there is (perhaps)\n>>>> a bug in ash.c.\n>>>>\n>>>> how can i do that ?\n>>> You don't need any tags for bisecting. The man page of git-bisect has\n>>> several examples on how to use it. Do you have a test script which\n>>> exposes the bug?\n>> unfortunately no, the error shows up very nicely when booting my\n>> embdedded system but not else (this is the reason i would to bisect that\n>> file only and not busybox completely). And from the man pages i got the\n>> impression that it is only possible the start with a tag.\n> \n> The man page says:\n> \n> git bisect start [ [...]] [--] [...]\n> \n> and then:\n> \n> \"This command uses git rev-list --bisect to help drive the binary search \n> process to find which change introduced a bug, given an old \"good\" commit \n> object name and a later \"bad\" commit object name.\"\n\n\ni am sorry, i am not familiar with git and when i am stating i am looking\nfor examples first. the examples in my man page are like\ngit bisect start v2.6.20-rc6 v2.6.20-rc4\nthere is nothing like:\ngit bisect start 6a87a68a6a8 65a76a8a68a7\n\nI ASSUME that you can use tags like \"v2.6.20-rc6\" and commit-id like \"6a87a68a6a8\"\ninterchangeable but that was not clear from beginning.\nBTW did you notice the sentence says \"commit object name\" not \"commit id\" ? when\nyou are starting you are not familiar with the wording so you do not make the connection.\n\n\n>> i already had the hint that i need to do:\n>> git bisect start bad_commit_id good_commit_id -- ash.c\n> \n> So did you try that?\n> \n\nnot yet, we are still using an older version of BB for production. So there is no hurry.\nThe problem is that we can not found the reason for the bug. NTL i plan for this week.\n\n\n>> Ntl, there is one more question, how can i make sure that\n>> i use the right version ?\n> \n> If you mean the right git version, then I think any 1.6.X should be enough.\n> \n>> first i toughed that cherry-pick is the right \n>> idea but it seems that that will apply onyl certain patches ?\n> \n> If you want to find the commit that introduced a bug, then you should not \n> need cherry-pick.\n> \n\nmmh, no, the idea was to use something like\n\ngit \"checkou\" and having a version that represents THAT moment.\n\n\nre,\n wh\n\n> Regards,\n> Christian.\n> \n"},{"id":"129566","messageId":"7vein5e2lc.fsf@alter.siamese.dyndns.org","threadId":"21889","inReplyTo":"4B1E5796.2090201@bfs.de","subject":"Re: help: bisect single file from repos","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-08T18:35:11Z","receivedAt":"2009-12-08T18:35:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"walter harms writes:\n\n> Christian Couder schrieb:\n> ...\n> i am sorry, i am not familiar with git and when i am stating i am looking\n> for examples first. the examples in my man page are like\n> git bisect start v2.6.20-rc6 v2.6.20-rc4\n> there is nothing like:\n> git bisect start 6a87a68a6a8 65a76a8a68a7\n>\n> I ASSUME that you can use tags like \"v2.6.20-rc6\" and commit-id like \"6a87a68a6a8\"\n> interchangeable but that was not clear from beginning.\n\nThe misconception here is \"naming commit is done completely differently\nfrom naming branches and tags\", which is false in the git land, but it may\nhold true in some other systems (e.g. Subversion, which made them into\ndifferent dimensions by making branches and tags into a location in a\nlarger whole tree namespace when their commits are named by serial version\nnumber of that whole tree namespace).\n\nWe can call this a misconception, tell users to learn how things work\nbefore using git (sometimes unlearning CVS and Subversion helps for this\nexact reason), dismiss the issue and move on. But I wonder if there is\nsomething we _could_ have done better in the documentation area to avoid\nthis from the beginning, iow, make it easier to \"learn how things work\nbefore using\"? I think there is a lesson to be learned by us in here, and\nI'd like to hear comments and improvement suggestions, especially from\n\"usability\" and \"friendly to new people\" advocates.\n"},{"id":"129593","messageId":"20091209012855.GA3208@neumann","threadId":"21889","inReplyTo":"7vein5e2lc.fsf@alter.siamese.dyndns.org","subject":"Re: help: bisect single file from repos","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2009-12-09T01:28:55Z","receivedAt":"2009-12-09T01:28:55Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Hi,\n\n\nOn Tue, Dec 08, 2009 at 10:35:11AM -0800, Junio C Hamano wrote:\n> But I wonder if there is\n> something we _could_ have done better in the documentation area to avoid\n> this from the beginning, iow, make it easier to \"learn how things work\n> before using\"? I think there is a lesson to be learned by us in here, and\n> I'd like to hear comments and improvement suggestions, especially from\n> \"usability\" and \"friendly to new people\" advocates.\n\nwhen a git command accepts a commit as command line option, the\ndocumentation usually refers to the \"Specifying revisions\" section of\n'git rev-parse's docs for \"a more complete list of ways to spell\ncommits\"[1]. Even the docs of porcelain commands and the user manual\ndo that. But 'git rev-parse' is plumbing, and we actively advertise\nthat avarage users don't really need to know about plumbing at all.\nWhile new to git I repeatedly encountered this reference to 'git\nrev-parse' all over the porcelain manpages, and it was a real burden\nfor me back then. I was like \"but I don't want to know about all the\nglory details, just give me a short summary\".\n\nI think the user should not refer to plumbing manpages to be able to\nuse porcelain commands. Therefore, the manpage of every command\naccepting a commit option need to have a section about specifying\nthese commits. This section doesn't need to be as detailed as 'git\nrev-parse'; perhaps we don't need to discuss the ^{} notation there.\nAlso, the precedence in case of an ambiguous symbolic ref name should\nbe described without reference to the internal $GIT_DIR/refs/\ndirectory structure.\n\nFurthermore, some manpages use the term \"\", while others\n\"\" or \"\". The same term should be used everywhere.\n\n\nBest,\nGábor\n\n\n[1] - 'git cherry-pick' doc says the following:\n\n \n Commit to cherry-pick. For a more complete list of ways to spell\n commits, see the \"SPECIFYING REVISIONS\" section in git-rev-parse(1).\n\nWhat? \"A _more_ complete list\"!? Well, it's not very hard to be more\ncomplete than this, there is not a single way described here (;\n"},{"id":"129610","messageId":"20091209172737.6117@nanako3.lavabit.com","threadId":"21889","inReplyTo":"20091209012855.GA3208@neumann","subject":"Re: help: bisect single file from repos","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-12-09T08:27:37Z","receivedAt":"2009-12-09T08:27:37Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting SZEDER Gábor \n\n> [1] - 'git cherry-pick' doc says the following:\n>\n> \n> Commit to cherry-pick. For a more complete list of ways to spell\n> commits, see the \"SPECIFYING REVISIONS\" section in git-rev-parse(1).\n>\n> What? \"A _more_ complete list\"!? Well, it's not very hard to be more\n> complete than this, there is not a single way described here (;\n\nI agree that \"more\" shouldn't be in that sentence, and I understand your hesitation to read plumbing manual pages, but I don't think it is a sane solution to the issue to repeat how to name a commit in manual pages for every single command to bloat the two line description you quoted into a half-page paragraph. Even within that two lines, the real information that should be in the manual for cherry-pick is only three words \"Commit to cherry-pick\" and the rest is to help people who don't know.\n\nMaybe it is a better idea to rewrite this to \"See 'basic concepts' manual for how to specify a commit\", and create a new 'basic concepts' manual that describes these things the readers must know to effectively use the main part of the manual. And make sure that we try very hard to keep the 'basic concepts' manual short, by eg. making a goal to keep it less than N printed pages.\n\nTo decide the value of 'N', somebody needs to first think and list the topics that need to be covered by 'basic concepts'. Something like this?\n\n * What are committed states, the state in the index and the state in the working tree.\n * How to name a commit.\n * How to name a range of commit (move part from the rev-parse manual).\n * How to specify options, revisions and files on command line (move part from the gitcli manual).\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"129617","messageId":"20091209094532.GS18686@neumann","threadId":"21889","inReplyTo":"20091209172737.6117@nanako3.lavabit.com","subject":"Re: help: bisect single file from repos","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2009-12-09T09:45:32Z","receivedAt":"2009-12-09T09:45:32Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Hi,\n\n\nOn Wed, Dec 09, 2009 at 05:27:37PM +0900, Nanako Shiraishi wrote:\n> Quoting SZEDER Gábor \n> \n> > [1] - 'git cherry-pick' doc says the following:\n> >\n> > \n> > Commit to cherry-pick. For a more complete list of ways to spell\n> > commits, see the \"SPECIFYING REVISIONS\" section in git-rev-parse(1).\n> >\n> > What? \"A _more_ complete list\"!? Well, it's not very hard to be more\n> > complete than this, there is not a single way described here (;\n> \n\n> I agree that \"more\" shouldn't be in that sentence, and I understand\n> your hesitation to read plumbing manual pages, but I don't think it\n> is a sane solution to the issue to repeat how to name a commit in\n> manual pages for every single command to bloat the two line\n> description you quoted into a half-page paragraph. Even within that\n> two lines, the real information that should be in the manual for\n> cherry-pick is only three words \"Commit to cherry-pick\" and the rest\n> is to help people who don't know.\n\nI agree, that's why I proposed \"a _section_ about specifying these\ncommits\" in the more relevant part of my previous email you did not\nquote.\n\nThe description of the \"\" option would remain almost the same,\nbut it will now refer to a dedicated section about specifying commits\nbelow, but still in the same manpage. This new dedicated section\nwould contain the list of three, five, N most common ways to specify a\ncommit, avoiding the bloatage in the options section. And for those\nwho really want to dig deep, this dedicated section will refer to 'git\nrev-parse' for the complete list.\n\nAnd this would not be the first time we document something in many\nplaces, think of '--pretty' and diff options, for example.\n\n\nBest,\nGábor\n"},{"id":"129627","messageId":"4B1F9444.9030000@bfs.de","threadId":"21889","inReplyTo":"20091209094532.GS18686@neumann","subject":"Re: help: bisect single file from repos","fromName":"walter harms","fromEmail":"wharms@bfs.de","sentAt":"2009-12-09T12:12:52Z","receivedAt":"2009-12-09T12:12:52Z","isPatch":false,"sender":{"key":"wharms@bfs.de","avatar":null},"body":"\n\nSZEDER Gábor schrieb:\n> Hi,\n> \n> \n> On Wed, Dec 09, 2009 at 05:27:37PM +0900, Nanako Shiraishi wrote:\n>> Quoting SZEDER Gábor \n>>\n>>> [1] - 'git cherry-pick' doc says the following:\n>>>\n>>> \n>>> Commit to cherry-pick. For a more complete list of ways to spell\n>>> commits, see the \"SPECIFYING REVISIONS\" section in git-rev-parse(1).\n>>>\n>>> What? \"A _more_ complete list\"!? Well, it's not very hard to be more\n>>> complete than this, there is not a single way described here (;\n> \n>> I agree that \"more\" shouldn't be in that sentence, and I understand\n>> your hesitation to read plumbing manual pages, but I don't think it\n>> is a sane solution to the issue to repeat how to name a commit in\n>> manual pages for every single command to bloat the two line\n>> description you quoted into a half-page paragraph. Even within that\n>> two lines, the real information that should be in the manual for\n>> cherry-pick is only three words \"Commit to cherry-pick\" and the rest\n>> is to help people who don't know.\n> \n> I agree, that's why I proposed \"a _section_ about specifying these\n> commits\" in the more relevant part of my previous email you did not\n> quote.\n> \n> The description of the \"\" option would remain almost the same,\n> but it will now refer to a dedicated section about specifying commits\n> below, but still in the same manpage. This new dedicated section\n> would contain the list of three, five, N most common ways to specify a\n> commit, avoiding the bloatage in the options section. And for those\n> who really want to dig deep, this dedicated section will refer to 'git\n> rev-parse' for the complete list.\n> \n> And this would not be the first time we document something in many\n> places, think of '--pretty' and diff options, for example.\n> \n> \n\nIt would be no problem when you have the description multiple times.\nImportant is that they use the same words for the same things\nand add examples. Most people that use git have a fair idea what they\nwant but not how to do it. git is new an you can not assume that\neven basic principles are known to the general (programmer) community.\nSo you need to make extra effort to explain it all over again.\n\nre,\n wh\n"}]}