{"thread":{"id":"35956","subject":"An idea for \"git bisect\" and a GSoC enquiry","startedAt":"2014-02-26T08:28:32Z","lastAt":"2014-03-13T18:47:50Z","messageCount":17,"participants":["Jacopo Notarstefano","Junio C Hamano","Michael Haggerty","Matthieu Moy","Christian Couder","Andrew Ardill"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"235355","messageId":"CAL0uuq0=Zo0X8mYRD6q-Q+QAcZhfmxOwKiRegDrRm3O_i0Q+EA@mail.gmail.com","threadId":"35956","inReplyTo":null,"subject":"An idea for \"git bisect\" and a GSoC enquiry","fromName":"Jacopo Notarstefano","fromEmail":"jacopo.notarstefano@gmail.com","sentAt":"2014-02-26T08:28:32Z","receivedAt":"2014-02-26T08:28:32Z","isPatch":false,"sender":{"key":"jacopo.notarstefano@gmail.com","avatar":"https://avatars.githubusercontent.com/u/381280?v=4"},"body":"Hey everyone,\n\nmy name is Jacopo, a student developer from Italy, and I'm interested\nin applying to this years' Google Summer of Code. I set my eyes on the\nproject called \"git-bisect improvements\", in particular the subtask\nabout swapping the \"good\" and \"bad\" labels when looking for a\nbug-fixing release.\n\nI have a very simple proposal for that: add a new \"mark\" subcommand.\nHere is an example of how it should work:\n\n1) A developer wants to find in which commit a past regression was\nfixed. She start bisecting as usual with \"git bisect start\".\n2) The current HEAD has the bugfix, so she marks it as fixed with \"git\nbisect mark fixed\".\n3) She knows that HEAD~100 had the regression, so she marks it as\nunfixed with \"git bisect mark unfixed\".\n4) Now that git knows what the two labels are, it starts bisecting as usual.\n\nFor compatibility with already written scripts, \"git bisect good\" and\n\"git bisect bad\" will alias to \"git bisect mark good\" and \"git bisect\nmark bad\" respectively.\n\nDoes this make sense? Did I overlook some details?\n\nThere were already several proposals on this topic, among which those\nlisted at https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed.\nI'm interested in contacting the prospective mentor, Christian Couder,\nto go over these. What's the proper way to ask for an introduction? I\ntried asking on IRC, but had no success.\n\nCheers,\nJacopo Notarstefano\n"},{"id":"235405","messageId":"xmqqzjld3ate.fsf@gitster.dls.corp.google.com","threadId":"35956","inReplyTo":"CAL0uuq0=Zo0X8mYRD6q-Q+QAcZhfmxOwKiRegDrRm3O_i0Q+EA@mail.gmail.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-26T19:58:53Z","receivedAt":"2014-02-26T19:58:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacopo Notarstefano writes:\n\n> Does this make sense? Did I overlook some details?\n\nHow does this solve the labels shown in \"git bisect visualize\"?\n"},{"id":"235455","messageId":"530F1F11.7060403@alum.mit.edu","threadId":"35956","inReplyTo":"CAL0uuq0=Zo0X8mYRD6q-Q+QAcZhfmxOwKiRegDrRm3O_i0Q+EA@mail.gmail.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-02-27T11:18:41Z","receivedAt":"2014-02-27T11:18:41Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/26/2014 09:28 AM, Jacopo Notarstefano wrote:\n> my name is Jacopo, a student developer from Italy, and I'm interested\n> in applying to this years' Google Summer of Code. I set my eyes on the\n> project called \"git-bisect improvements\", in particular the subtask\n> about swapping the \"good\" and \"bad\" labels when looking for a\n> bug-fixing release.\n\nHello and welcome!\n\n> I have a very simple proposal for that: add a new \"mark\" subcommand.\n> Here is an example of how it should work:\n> \n> 1) A developer wants to find in which commit a past regression was\n> fixed. She start bisecting as usual with \"git bisect start\".\n> 2) The current HEAD has the bugfix, so she marks it as fixed with \"git\n> bisect mark fixed\".\n> 3) She knows that HEAD~100 had the regression, so she marks it as\n> unfixed with \"git bisect mark unfixed\".\n> 4) Now that git knows what the two labels are, it starts bisecting as usual.\n> \n> For compatibility with already written scripts, \"git bisect good\" and\n> \"git bisect bad\" will alias to \"git bisect mark good\" and \"git bisect\n> mark bad\" respectively.\n> \n> Does this make sense? Did I overlook some details?\n\nI don't understand the benefit of adding a new command \"mark\" rather\nthan continuing to use \"good\", \"bad\", plus new commands \"unfixed\" and\n\"fixed\". Does this solve any problems?\n\nWhat happens if the user mixes, say, \"good\" and \"fixed\" in a single\nbisect session?\n\nI think it would be more convenient if \"git bisect\" would autodetect\nwhether the history went from \"good\" to \"bad\" or vice versa. The\nalgorithm could be:\n\n1. Wait until the user has marked one commit \"bad\" and one commit \"good\".\n\n2. If a \"good\" commit is an ancestor of a \"bad\" one, then \"git bisect\"\nshould announce \"I will now look for the first bad commit\". If\nreversed, then announce \"I will now look for the first good commit\". If\nneither commit is an ancestor of the other, then explain the situation\nand ask the user to run \"git bisect find-first-bad\" or \"git bisect\nfind-first-good\" or to mark another commit \"bad\" or \"good\".\n\n3. If the user marks another commit, go back to step 2, also doing a\nconsistency check to make sure that all of the ancestry relationships go\nin a consistent direction.\n\n4. After the direction is clear, the old bisect algorithm can be used\n(though taking account of the direction). Obviously a lot of the output\nwould have to be adjusted, as would the way that a bisect is visualized.\n\nI can't think of any fundamental problems with a scheme like this, and I\nthink it would be easier to use than the unfixed/fixed scheme. But that\nis only my opinion; other opinions are undoubtedly available :-)\n\n> There were already several proposals on this topic, among which those\n> listed at https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed.\n> I'm interested in contacting the prospective mentor, Christian Couder,\n> to go over these. What's the proper way to ask for an introduction? I\n> tried asking on IRC, but had no success.\n\nJust CC Christian on your emails to the mailing list, like I've done\nwith this email. As a rule of thumb all communications should go to the\nmailing list *plus* any people who are likely to be personally\ninterested in the topic (e.g., because they have participated in the\nthread).\n\nBy the way, although \"git bisect fixed/unfixed\" would be a very useful\nimprovement, and has gone unimplemented for a lamentably long time, my\npersonal feeling is that it has too meat in it to constitute a GSoC\nproject by itself.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"235467","messageId":"239563375.177900.1393502992014.JavaMail.zimbra@imag.fr","threadId":"35956","inReplyTo":"530F1F11.7060403@alum.mit.edu","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-27T12:09:52Z","receivedAt":"2014-02-27T12:09:52Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"----- Original Message -----\n> I don't understand the benefit of adding a new command \"mark\" rather\n> than continuing to use \"good\", \"bad\", plus new commands \"unfixed\" and\n> \"fixed\". Does this solve any problems?\n\nI think it could be interesting to allow arbitrary words here. For example, I recently walked through history to find a performance regression, it would have been natural to use slow/fast instead of bad/good (bad/good would actually do the job, but slightly less naturally). One can look for a change which is neither a fix nor a bug (e.g. when did command foo start behaving like that? when did we start using such or such feature in the code).\n\nI wouldn't fight for it, but I think it makes sense.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235479","messageId":"CAP8UFD0Wd3FcgxW+Vb-YKACLqqaeF+AAf=YRScZd84t7qiNkjw@mail.gmail.com","threadId":"35956","inReplyTo":"CAL0uuq0=Zo0X8mYRD6q-Q+QAcZhfmxOwKiRegDrRm3O_i0Q+EA@mail.gmail.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-02-27T14:47:45Z","receivedAt":"2014-02-27T14:47:45Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Wed, Feb 26, 2014 at 9:28 AM, Jacopo Notarstefano\n wrote:\n> Hey everyone,\n>\n> my name is Jacopo, a student developer from Italy, and I'm interested\n> in applying to this years' Google Summer of Code. I set my eyes on the\n> project called \"git-bisect improvements\", in particular the subtask\n> about swapping the \"good\" and \"bad\" labels when looking for a\n> bug-fixing release.\n>\n> I have a very simple proposal for that: add a new \"mark\" subcommand.\n> Here is an example of how it should work:\n>\n> 1) A developer wants to find in which commit a past regression was\n> fixed. She start bisecting as usual with \"git bisect start\".\n> 2) The current HEAD has the bugfix, so she marks it as fixed with \"git\n> bisect mark fixed\".\n> 3) She knows that HEAD~100 had the regression, so she marks it as\n> unfixed with \"git bisect mark unfixed\".\n> 4) Now that git knows what the two labels are, it starts bisecting as usual.\n>\n> For compatibility with already written scripts, \"git bisect good\" and\n> \"git bisect bad\" will alias to \"git bisect mark good\" and \"git bisect\n> mark bad\" respectively.\n>\n> Does this make sense? Did I overlook some details?\n\nAs Junio said adding a command \"mark\" doesn't by itself solve the\ndifficult problems related to this project.\n(By the way I think it is misleading to state that this GSoC is \"easy\".)\n\n> There were already several proposals on this topic, among which those\n> listed at https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed.\n> I'm interested in contacting the prospective mentor, Christian Couder,\n> to go over these. What's the proper way to ask for an introduction?\n\nAs Michael said, you can just CC me or send me a private email.\n\nBut I think the most important thing right now is first to gather as\nmuch information as you can from the previous discussions on this\ntopic on this mainling list.\nPerhaps you should also gather information on how git bisect works.\n\nIt will help you understand what are the difficult problems.\n\nOne of the problems, for example, is that git bisect can work using a\n\"good\" commit that is not an ancestor of the \"bad\" commit.\nIn this case it will checkout the merge bases between the good and the\nbad commit. (And by the way this is related to the bug that should\nalso be fixed as part of this project.)\n\nThen you are welcome to come back and ask questions, or suggest solutions.\n\n> I tried asking on IRC, but had no success.\n\nSorry but I don't use IRC.\n\nThanks,\nChristian.\n"},{"id":"235524","messageId":"CAH5451mHOHb6xAGuqvVKBrB=jjjVJMbov1oBDdSNOG4p8MXRxQ@mail.gmail.com","threadId":"35956","inReplyTo":"CAP8UFD0Wd3FcgxW+Vb-YKACLqqaeF+AAf=YRScZd84t7qiNkjw@mail.gmail.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2014-02-27T22:46:44Z","receivedAt":"2014-02-27T22:46:44Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 27 February 2014 06:47, Christian Couder wrote:\n> But I think the most important thing right now is first to gather as\n> much information as you can from the previous discussions on this\n> topic on this mainling list.\n> Perhaps you should also gather information on how git bisect works.\n\nI have also, at one time, started working on this problem, though I\nnever submitted any of my patches :(. I went the way of renaming the\ninternal logic to make it less tied to the good/bad distinction that\nis currently hard coded in. That may not be the best starting point,\nbut let me summarise the thoughts I had at the time, particularly\naround the different adjective pairs that we might use.\n\nA general description of git bisect is that you start with a commit\nthat exhibits a given property, find a commit that does not have that\nproperty, and then look for when the property was introduced. I think\nof this property as the 'bisect property' of the bisect search. The\nproperty is described with our adjective pair, currently 'bad' (with\nthe property) and 'good' (without the property). We assume that\ncommits with the property have an ancestor without the property, and\nas this assumption is so essential to how git bisect works I think of\nit as the 'bisect relationship' of the bisect search, and we care\nabout the direction of this relationship between commits.\n\nThe proposed adjectives tend to be along the lines of the following:\n\n- good->bad (current); good<->bad\nThe bisect property is currently always described as 'bad', the\nintroduction of a bug being the motivating use case. The problem with\nthis is that we often want to find when a 'good' behaviour was\nintroduced, or when a neutral change occurred.\nA solution is to allow reversing our bisect relationship, by either\ndetecting the intended direction or allowing the user to choose. If we\nreverse the direction our adjectives also flip, and so the bisect\nproperty we are now looking for is 'good' instead of 'bad'. The terms\ngood and bad don't work well with neutral searches.\n\n- unfixed->fixed\nFor this pair, the bisect property would always be described by the\n'fixed' adjective. It seems odd to ever reverse the bisect\nrelationship, as we don't usually say something was 'fixed' and then\nbecame 'unfixed'. The behaviour of this pair would thus be near\nidentical to current usage of 'good->bad', but with the bisect\nproperty conceptually reversed (when was a bug fixed vs when was a bug\nintroduced).\n\n- old->new\nThis pair avoids making any judgement on what type of bisect property\nwe have. The adjectives are thus simply describing the bisect\nrelationship, and the user is free to use any bisect property they\nwish. The main problem with this is that it is possible to have\ncommits without the property (thus described as 'old') that were made\nchronologically after a commit with the property ('new'). This has the\npotential to cause confusion for users.\n\n- without->with\nThis pair also avoids making a judgement on the bisect property, but\navoids potential chronological confusion that 'old->new' has. You\ncould potentially allow users to reverse the bisect relationship's\ndirection, but these adjectives allow you to easily invert the bisect\nproperty without causing confusion. For example, 'without bug XYZ' can\ninstead be written as 'with bug XYZ fixed'.\n\n----\n\nMy preference is for the without->with adjective pair, as I believe it\nmaps most closely to the concept of finding a commit that changed a\ngiven property, and it allows that property to be negated without\nintroducing too much confusion. Reversing the relationship's direction\nwould also make sense, however that is a significantly greater change\nto the commands logic.\n\nThus, my initial work was to refactor the internal naming to use the\nterms with and without, as that would make a better place from which\nto add other features (such as reversing the relationship direction,\nor adding new adjective pairs).\n\nSorry if that is all confusing to read, or if I'm repeating things\nthat have been said before :)\n\nRegards,\n\nAndrew Ardill\n"},{"id":"235559","messageId":"CAL0uuq23E+2gX14yAyeGFPySV0qTF8=-642PHqmogTDwz7F8Sg@mail.gmail.com","threadId":"35956","inReplyTo":"xmqqzjld3ate.fsf@gitster.dls.corp.google.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Jacopo Notarstefano","fromEmail":"jacopo.notarstefano@gmail.com","sentAt":"2014-02-28T09:00:53Z","receivedAt":"2014-02-28T09:00:53Z","isPatch":false,"sender":{"key":"jacopo.notarstefano@gmail.com","avatar":"https://avatars.githubusercontent.com/u/381280?v=4"},"body":"Mh. Haven't thought of that. I have no experience with TK, so I'm\nhaving trouble digging up where the \"good\" and \"bad\" labels in the GUI\nare generated.\n\nI guess that a solution might involve writing a temporary file in\n$GIT_DIR called something like BISECT_LABELS in which the chosen\nlabels are listed and reused across all tools that require them.\n\n(Sorry for sending this email twice, I thought I had sent it to the\nlist as well!)\n\nOn Wed, Feb 26, 2014 at 8:58 PM, Junio C Hamano wrote:\n> Jacopo Notarstefano writes:\n>\n>> Does this make sense? Did I overlook some details?\n>\n> How does this solve the labels shown in \"git bisect visualize\"?\n>\n"},{"id":"235561","messageId":"CAL0uuq0msXWZDDWzpetfBG0cgGQLKrtwhNp-DqbD6Q3aytaCdQ@mail.gmail.com","threadId":"35956","inReplyTo":"530F1F11.7060403@alum.mit.edu","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Jacopo Notarstefano","fromEmail":"jacopo.notarstefano@gmail.com","sentAt":"2014-02-28T09:03:15Z","receivedAt":"2014-02-28T09:03:15Z","isPatch":false,"sender":{"key":"jacopo.notarstefano@gmail.com","avatar":"https://avatars.githubusercontent.com/u/381280?v=4"},"body":"On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty wrote:\n> I don't understand the benefit of adding a new command \"mark\" rather\n> than continuing to use \"good\", \"bad\", plus new commands \"unfixed\" and\n> \"fixed\". Does this solve any problems?\n>\n\nAs Matthieu Moy remarked in a previous email, the main reason is\nextensibility: I prefer having a single command to assign new\ndescriptive labels instead of having to patch git-bisect.sh to create\nnew labels like fixed, unfixed, fast, slow...\n\n> What happens if the user mixes, say, \"good\" and \"fixed\" in a single\n> bisect session?\n>\n\nI don't think that's an issue. If the user uses the label \"fixed\"\ninstead of \"bad\" she will have a hard time remembering to use it every\ntime she needs it, and maybe the output of \"git bisect\" will look very\nconfusing, but what can git do? This is a semantic user input error,\nnot a syntax one.\n\n> I think it would be more convenient if \"git bisect\" would autodetect\n> whether the history went from \"good\" to \"bad\" or vice versa. The\n> algorithm could be:\n>\n> 1. Wait until the user has marked one commit \"bad\" and one commit \"good\".\n>\n> 2. If a \"good\" commit is an ancestor of a \"bad\" one, then \"git bisect\"\n> should announce \"I will now look for the first bad commit\". If\n> reversed, then announce \"I will now look for the first good commit\". If\n> neither commit is an ancestor of the other, then explain the situation\n> and ask the user to run \"git bisect find-first-bad\" or \"git bisect\n> find-first-good\" or to mark another commit \"bad\" or \"good\".\n>\n> 3. If the user marks another commit, go back to step 2, also doing a\n> consistency check to make sure that all of the ancestry relationships go\n> in a consistent direction.\n>\n> 4. After the direction is clear, the old bisect algorithm can be used\n> (though taking account of the direction). Obviously a lot of the output\n> would have to be adjusted, as would the way that a bisect is visualized.\n>\n> I can't think of any fundamental problems with a scheme like this, and I\n> think it would be easier to use than the unfixed/fixed scheme. But that\n> is only my opinion; other opinions are undoubtedly available :-)\n>\n\nI like this idea! It also looks fun to implement. A minor difference\nis that I'd rather die with an error on point 2) if there's no\nancestorship relation between the two commits; if the user is asking\nfor such a thing then she has a fundamental misconception of the state\nof her repository.\n\n> By the way, although \"git bisect fixed/unfixed\" would be a very useful\n> improvement, and has gone unimplemented for a lamentably long time, my\n> personal feeling is that it has too meat in it to constitute a GSoC\n> project by itself.\n\nOh! Then in fact, as Christian Couder said, this project shouldn't be\nmarked as \"easy\".\n\n(Sorry for sending this email twice! I thought I had sent it to the\nlist as well.)\n\nOn Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty wrote:\n> On 02/26/2014 09:28 AM, Jacopo Notarstefano wrote:\n>> my name is Jacopo, a student developer from Italy, and I'm interested\n>> in applying to this years' Google Summer of Code. I set my eyes on the\n>> project called \"git-bisect improvements\", in particular the subtask\n>> about swapping the \"good\" and \"bad\" labels when looking for a\n>> bug-fixing release.\n>\n> Hello and welcome!\n>\n>> I have a very simple proposal for that: add a new \"mark\" subcommand.\n>> Here is an example of how it should work:\n>>\n>> 1) A developer wants to find in which commit a past regression was\n>> fixed. She start bisecting as usual with \"git bisect start\".\n>> 2) The current HEAD has the bugfix, so she marks it as fixed with \"git\n>> bisect mark fixed\".\n>> 3) She knows that HEAD~100 had the regression, so she marks it as\n>> unfixed with \"git bisect mark unfixed\".\n>> 4) Now that git knows what the two labels are, it starts bisecting as usual.\n>>\n>> For compatibility with already written scripts, \"git bisect good\" and\n>> \"git bisect bad\" will alias to \"git bisect mark good\" and \"git bisect\n>> mark bad\" respectively.\n>>\n>> Does this make sense? Did I overlook some details?\n>\n> I don't understand the benefit of adding a new command \"mark\" rather\n> than continuing to use \"good\", \"bad\", plus new commands \"unfixed\" and\n> \"fixed\". Does this solve any problems?\n>\n> What happens if the user mixes, say, \"good\" and \"fixed\" in a single\n> bisect session?\n>\n> I think it would be more convenient if \"git bisect\" would autodetect\n> whether the history went from \"good\" to \"bad\" or vice versa. The\n> algorithm could be:\n>\n> 1. Wait until the user has marked one commit \"bad\" and one commit \"good\".\n>\n> 2. If a \"good\" commit is an ancestor of a \"bad\" one, then \"git bisect\"\n> should announce \"I will now look for the first bad commit\". If\n> reversed, then announce \"I will now look for the first good commit\". If\n> neither commit is an ancestor of the other, then explain the situation\n> and ask the user to run \"git bisect find-first-bad\" or \"git bisect\n> find-first-good\" or to mark another commit \"bad\" or \"good\".\n>\n> 3. If the user marks another commit, go back to step 2, also doing a\n> consistency check to make sure that all of the ancestry relationships go\n> in a consistent direction.\n>\n> 4. After the direction is clear, the old bisect algorithm can be used\n> (though taking account of the direction). Obviously a lot of the output\n> would have to be adjusted, as would the way that a bisect is visualized.\n>\n> I can't think of any fundamental problems with a scheme like this, and I\n> think it would be easier to use than the unfixed/fixed scheme. But that\n> is only my opinion; other opinions are undoubtedly available :-)\n>\n>> There were already several proposals on this topic, among which those\n>> listed at https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed.\n>> I'm interested in contacting the prospective mentor, Christian Couder,\n>> to go over these. What's the proper way to ask for an introduction? I\n>> tried asking on IRC, but had no success.\n>\n> Just CC Christian on your emails to the mailing list, like I've done\n> with this email. As a rule of thumb all communications should go to the\n> mailing list *plus* any people who are likely to be personally\n> interested in the topic (e.g., because they have participated in the\n> thread).\n>\n> By the way, although \"git bisect fixed/unfixed\" would be a very useful\n> improvement, and has gone unimplemented for a lamentably long time, my\n> personal feeling is that it has too meat in it to constitute a GSoC\n> project by itself.\n>\n> Michael\n>\n> --\n> Michael Haggerty\n> mhagger@alum.mit.edu\n> http://softwareswirl.blogspot.com/\n"},{"id":"235563","messageId":"CAL0uuq33i6jU1A4Vv4xUO7=QZRej0vxVM12SKxvOiLk27hsD2A@mail.gmail.com","threadId":"35956","inReplyTo":"a8cf74b4-bae1-4511-a45e-d4ca90e3c3e1@email.android.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Jacopo Notarstefano","fromEmail":"jacopo.notarstefano@gmail.com","sentAt":"2014-02-28T09:07:55Z","receivedAt":"2014-02-28T09:07:55Z","isPatch":false,"sender":{"key":"jacopo.notarstefano@gmail.com","avatar":"https://avatars.githubusercontent.com/u/381280?v=4"},"body":"This email was sent privately by Michael to me as a result of my\nprevious error. I'm quoting it in its entirety so that he doesn't have\nto submit it twice.\n\nOn Thu, Feb 27, 2014 at 8:32 PM, Michael Haggerty wrote:\n> Please forgive my typos and brevity; this was typed on a phone.\n>\n> Michael\n> On February 27, 2014 5:16:40 PM CET, Jacopo Notarstefano wrote:\n>>On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty\n>> wrote:\n>>> What happens if the user mixes, say, \"good\" and \"fixed\" in a single\n>>> bisect session?\n>>>\n>>\n>>I don't think that's an issue. If the user uses the label \"fixed\"\n>>instead of \"bad\" she will have a hard time remembering to use it every\n>>time she needs it, and maybe the output of \"git bisect\" will look very\n>>confusing, but what can git do? This is a semantic user input error,\n>>not a syntax one.\n>\n> - git could emit an error message and refuse to continue\n> - git could interpret the command one way or the other, with or without a warning\n>\n> By my count that gives at least five possibilities. The feature cannot be implemented without choosing one.\n>\n>>> I think it would be more convenient if \"git bisect\" would autodetect\n>>> whether the history went from \"good\" to \"bad\" or vice versa. The\n>>> algorithm could be:\n>>>\n>>> 1. Wait until the user has marked one commit \"bad\" and one commit\n>>\"good\".\n>>>\n>>> 2. If a \"good\" commit is an ancestor of a \"bad\" one, then \"git\n>>bisect\"\n>>> should announce \"I will now look for the first bad commit\". If\n>>> reversed, then announce \"I will now look for the first good commit\".\n>>If\n>>> neither commit is an ancestor of the other, then explain the\n>>situation\n>>> and ask the user to run \"git bisect find-first-bad\" or \"git bisect\n>>> find-first-good\" or to mark another commit \"bad\" or \"good\".\n>>>\n>>> 3. If the user marks another commit, go back to step 2, also doing a\n>>> consistency check to make sure that all of the ancestry relationships\n>>go\n>>> in a consistent direction.\n>>>\n>>> 4. After the direction is clear, the old bisect algorithm can be used\n>>> (though taking account of the direction). Obviously a lot of the\n>>output\n>>> would have to be adjusted, as would the way that a bisect is\n>>visualized.\n>>>\n>>> I can't think of any fundamental problems with a scheme like this,\n>>and I\n>>> think it would be easier to use than the unfixed/fixed scheme. But\n>>that\n>>> is only my opinion; other opinions are undoubtedly available :-)\n>>>\n>>\n>>I like this idea! It also looks fun to implement. A minor difference\n>>is that I'd rather die with an error on point 2) if there's no\n>>ancestorship relation between the two commits; if the user is asking\n>>for such a thing then she has a fundamental misconception of the state\n>>of her repository.\n>\n> That is not correct. If there is a bug on one branch but not another, it is legitimate to ask when the bug was introduced, and git bisect can indeed handle this case today (think about how this could work, and try it!)\n>\n>>> By the way, although \"git bisect fixed/unfixed\" would be a very\n>>useful\n>>> improvement, and has gone unimplemented for a lamentably long time,\n>>my\n>>> personal feeling is that it has too meat in it to constitute a GSoC\n>>> project by itself.\n>>>\n>>\n>>Oh! Then in fact, as Christian Couder said, this project shouldn't be\n>>marked as \"easy\".\n>\n> Sorry for the typo; I meant to say \"too LITTLE meat\".\n>\n>\n> --\n> Michael Haggerty\n> mhagger@alum.mit.edu\n"},{"id":"235566","messageId":"CAL0uuq2CYg58p2NpSL0f9N6y3qMgUEpamhk2iKi3xdgB1Lv9bw@mail.gmail.com","threadId":"35956","inReplyTo":"a8cf74b4-bae1-4511-a45e-d4ca90e3c3e1@email.android.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Jacopo Notarstefano","fromEmail":"jacopo.notarstefano@gmail.com","sentAt":"2014-02-28T09:13:38Z","receivedAt":"2014-02-28T09:13:38Z","isPatch":false,"sender":{"key":"jacopo.notarstefano@gmail.com","avatar":"https://avatars.githubusercontent.com/u/381280?v=4"},"body":"> - git could emit an error message and refuse to continue\n> - git could interpret the command one way or the other, with or without a warning\n>\n> By my count that gives at least five possibilities. The feature cannot be implemented without choosing one.\n>\n\nLet me explain what I meant with an example.\n1) The user starts bisecting with bisect start.\n2) The user marks HEAD as good with git bisect mark good.\n3) The user then marks HEAD~10 as fixed with git bisect mark fixed.\n4) Git will then continue bisecting as usual with the labels \"good\"\nand \"fixed\" instead of \"bad\" and \"good\" respectively.\n\nThis is very confusing, but is a result of a user semantic error, so\nno warning is emitted. After all, this might have been what the user\nwanted.\n\n> That is not correct. If there is a bug on one branch but not another, it is legitimate to ask when the bug was introduced, and git bisect can indeed handle this case today (think about how this could work, and try it!)\n>\n\nInteresting. I did not know that. Yes, I see how that might pan out,\nand why my idea is worse.\n\n> Sorry for the typo; I meant to say \"too LITTLE meat\".\n>\n\nOk. Not a big issue for me: I might squash another project together in\nmy proposal. I've already seen one that piqued my interest: \"Unifying\ngit branch -l, git tag -l, and git for-each-ref\".\n\n(Sorry for sending this email twice! I thought I had sent it to the\nlist as well.)\n\nOn Thu, Feb 27, 2014 at 8:32 PM, Michael Haggerty wrote:\n> Please forgive my typos and brevity; this was typed on a phone.\n>\n> Michael\n> On February 27, 2014 5:16:40 PM CET, Jacopo Notarstefano wrote:\n>>On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty\n>> wrote:\n>>> What happens if the user mixes, say, \"good\" and \"fixed\" in a single\n>>> bisect session?\n>>>\n>>\n>>I don't think that's an issue. If the user uses the label \"fixed\"\n>>instead of \"bad\" she will have a hard time remembering to use it every\n>>time she needs it, and maybe the output of \"git bisect\" will look very\n>>confusing, but what can git do? This is a semantic user input error,\n>>not a syntax one.\n>\n> - git could emit an error message and refuse to continue\n> - git could interpret the command one way or the other, with or without a warning\n>\n> By my count that gives at least five possibilities. The feature cannot be implemented without choosing one.\n>\n>>> I think it would be more convenient if \"git bisect\" would autodetect\n>>> whether the history went from \"good\" to \"bad\" or vice versa. The\n>>> algorithm could be:\n>>>\n>>> 1. Wait until the user has marked one commit \"bad\" and one commit\n>>\"good\".\n>>>\n>>> 2. If a \"good\" commit is an ancestor of a \"bad\" one, then \"git\n>>bisect\"\n>>> should announce \"I will now look for the first bad commit\". If\n>>> reversed, then announce \"I will now look for the first good commit\".\n>>If\n>>> neither commit is an ancestor of the other, then explain the\n>>situation\n>>> and ask the user to run \"git bisect find-first-bad\" or \"git bisect\n>>> find-first-good\" or to mark another commit \"bad\" or \"good\".\n>>>\n>>> 3. If the user marks another commit, go back to step 2, also doing a\n>>> consistency check to make sure that all of the ancestry relationships\n>>go\n>>> in a consistent direction.\n>>>\n>>> 4. After the direction is clear, the old bisect algorithm can be used\n>>> (though taking account of the direction). Obviously a lot of the\n>>output\n>>> would have to be adjusted, as would the way that a bisect is\n>>visualized.\n>>>\n>>> I can't think of any fundamental problems with a scheme like this,\n>>and I\n>>> think it would be easier to use than the unfixed/fixed scheme. But\n>>that\n>>> is only my opinion; other opinions are undoubtedly available :-)\n>>>\n>>\n>>I like this idea! It also looks fun to implement. A minor difference\n>>is that I'd rather die with an error on point 2) if there's no\n>>ancestorship relation between the two commits; if the user is asking\n>>for such a thing then she has a fundamental misconception of the state\n>>of her repository.\n>\n> That is not correct. If there is a bug on one branch but not another, it is legitimate to ask when the bug was introduced, and git bisect can indeed handle this case today (think about how this could work, and try it!)\n>\n>>> By the way, although \"git bisect fixed/unfixed\" would be a very\n>>useful\n>>> improvement, and has gone unimplemented for a lamentably long time,\n>>my\n>>> personal feeling is that it has too meat in it to constitute a GSoC\n>>> project by itself.\n>>>\n>>\n>>Oh! Then in fact, as Christian Couder said, this project shouldn't be\n>>marked as \"easy\".\n>\n> Sorry for the typo; I meant to say \"too LITTLE meat\".\n>\n>\n> --\n> Michael Haggerty\n> mhagger@alum.mit.edu\n"},{"id":"235652","messageId":"xmqqtxbjum06.fsf@gitster.dls.corp.google.com","threadId":"35956","inReplyTo":"CAL0uuq0msXWZDDWzpetfBG0cgGQLKrtwhNp-DqbD6Q3aytaCdQ@mail.gmail.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-28T18:31:53Z","receivedAt":"2014-02-28T18:31:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacopo Notarstefano writes:\n\n> On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty wrote:\n>> I don't understand the benefit of adding a new command \"mark\" rather\n>> than continuing to use \"good\", \"bad\", plus new commands \"unfixed\" and\n>> \"fixed\". Does this solve any problems?\n>>\n>\n> As Matthieu Moy remarked in a previous email, the main reason is\n> extensibility: I prefer having a single command to assign new\n> descriptive labels instead of having to patch git-bisect.sh to create\n> new labels like fixed, unfixed, fast, slow...\n>\n>> What happens if the user mixes, say, \"good\" and \"fixed\" in a single\n>> bisect session?\n>\n> I don't think that's an issue. If the user uses the label \"fixed\"\n> instead of \"bad\" she will have a hard time remembering to use it every\n> time she needs it,...\n\nI am not sure I understand what you are trying to say. Are you\nsaying that we should stick to good/bad and allow the users use\nnothing else, because allowing \"fixed\" will be confusing?\n\n> and maybe the output of \"git bisect\" will look very\n> confusing, but what can git do? This is a semantic user input error,\n> not a syntax one.\n\nFor a young tool or a feature, catering to perfect human perfectly\nis a good first goal---if it does not work well even for error-free\nhuman input, it would be worthless. However, its second goal after\nachieving that first goal ought to be to help imperfect humans.\n\nI can very well imagine somebody start hunting for an earlier bugfix\n(perhaps trying to find it to backport to an older maintenance\ntrack), start saying \"fixed\", \"broken\", \"broken\", ..., continue\nafter leaving for lunch for a while, and then try to mark the next\nversion he tests as \"bad\" because it has a bug.\n\nIt technically may be an user error, in the sense that in such a\n\"where is the fix?\" session, you want to mark a \"still-has-bug\" one\nas \"broken\" and mark a \"no-longer-has-bug\" one as \"fixed\" (just like\n\"still-broken\" as \"bad\" and \"no-longer-broken\" as \"good\" in regular\nbisection). But at that point, the tool *knows* that the user\nearlier used \"fixed\" (or \"broken\") to mark some commits *already*.\n\nWhy do you think there is nothing it can do to help the user? Upon\nseeing \"bad\", the tool should at least be able to say \"Excuse me,\nbut you earlier said 'fixed' for one of the commits, so your\nvocabulary now is limited to 'fixed' and 'broken'\". I think it also\nshould be able to add \"Did you mean to say 'broken'?\", or even \"I'd\nassume that you meant 'broken' and will continue.\"\n\nI have always wondered if we can introduce a value neutral synonyms\nto good and bad. For a bisect session, we care only about two\nstates: \"still-X\" and \"no-longer-X\" where X may be 'working' for the\nnormal bug-hunting bisection and 'broken' for the fix-hunting one.\n\n\t$ git bisect still-working v1.6.0\n $ git bisect no-longer-working v1.8.0\n\nwould be a way to find a bug that was introduced during v1.6.0..v1.8.0,\nwhile\n\n $ git bisect still-broken v1.6.0\n $ git bisect no-longer-broken v1.8.0\n\nwould be a way to find a fix in the same range. The lowest-level\nbisection machinery could just _ignore_ anything after still/no-longer\nand do its thing, while the end-user facing layer could enforce,\nonce one commit is marked as still-X (or no-longer-X), that nothing\nother than the same X is used, and issue an error message, perhaps\nlike this:\n\n\t$ git bisect still-broken v1.6.0\n $ git bisect still-working v1.8.0\n error: You earlier marked v1.6.0 as \"still-broken\" and\n error: are hunting for the first commit that can be marked\n error: as \"no-longer-broken\". Say either \"still-broken\" or\n error: \"no-longer-broken\", not \"still-working\".\n\nand that can be done without having to understand that \"broken\" is\nthe opposite of \"working\" (of course if we understood that, we could\neven offer to guess that the user meant \"no-longer-broken\" by\n\"still-working\", but we do not want to go there).\n"},{"id":"235713","messageId":"CAL0uuq3eWnLz3=wiexSsJgArUYx95EjLMDWyDvQb9=_ieQUvBA@mail.gmail.com","threadId":"35956","inReplyTo":"xmqqtxbjum06.fsf@gitster.dls.corp.google.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Jacopo Notarstefano","fromEmail":"jacopo.notarstefano@gmail.com","sentAt":"2014-03-01T11:31:58Z","receivedAt":"2014-03-01T11:31:58Z","isPatch":false,"sender":{"key":"jacopo.notarstefano@gmail.com","avatar":"https://avatars.githubusercontent.com/u/381280?v=4"},"body":"> I am not sure I understand what you are trying to say. Are you\n> saying that we should stick to good/bad and allow the users use\n> nothing else, because allowing \"fixed\" will be confusing?\n>\n\nNo! Pretty much the opposite of that. My idea (the \"mark\" subcommand)\nis to let people define their own pairs of labels to represent two\nopposite states of a commit. My point was that, if people choose pairs\nof words that are not opposites (such as \"good\" and \"fixed\") then it's\ntheir error, not something that git should attempt to fix or detect.\n\n> For a young tool or a feature, catering to perfect human perfectly\n> is a good first goal---if it does not work well even for error-free\n> human input, it would be worthless. However, its second goal after\n> achieving that first goal ought to be to help imperfect humans.\n>\n\nLoved this.\n\n> Why do you think there is nothing it can do to help the user? Upon\n> seeing \"bad\", the tool should at least be able to say \"Excuse me,\n> but you earlier said 'fixed' for one of the commits, so your\n> vocabulary now is limited to 'fixed' and 'broken'\". I think it also\n> should be able to add \"Did you mean to say 'broken'?\", or even \"I'd\n> assume that you meant 'broken' and will continue.\"\n>\n\nI haven't said this, but this is pretty much what I had in mind.\nSuppose a user wants to find a bugfix between HEAD and HEAD~10, this\nis what she would do:\n\n$ git bisect start\n$ git bisect mark working HEAD\n$ git bisect mark broken HEAD~10\n\n[git will now start bisecting as usual. Suppose that she is now at HEAD~5]\n\n$ git bisect mark bad\n-> Error: unrecognized label 'bad'. You previously used 'working' and\n'fixed' to describe commits in this git bisect session. Please mark\ncommits with one of these labels.\n\nI suppose that we could cater a little better to imperfect humans if\nwe had two predefined parallel list of antonyms in which to search for\ngiven labels and infer whether they are positive or negative labels,\nbut this is beyond the scope of my proposal.\n\n> I have always wondered if we can introduce a value neutral synonyms\n> to good and bad. For a bisect session, we care only about two\n> states: \"still-X\" and \"no-longer-X\" where X may be 'working' for the\n> normal bug-hunting bisection and 'broken' for the fix-hunting one.\n>\n> $ git bisect still-working v1.6.0\n> $ git bisect no-longer-working v1.8.0\n>\n> would be a way to find a bug that was introduced during v1.6.0..v1.8.0,\n> while\n>\n> $ git bisect still-broken v1.6.0\n> $ git bisect no-longer-broken v1.8.0\n>\n> would be a way to find a fix in the same range. The lowest-level\n> bisection machinery could just _ignore_ anything after still/no-longer\n> and do its thing, [...]\n\nThis is remarkably similar to my proposal. Using \"mark\", these would be:\n\n$ git bisect mark working v1.6.0\n$ git bisect mark not-working v1.8.0\n\nand\n\n$ git bisect mark broken v1.6.0\n$ git bisect mark not-broken v1.8.0\n\n> while the end-user facing layer could enforce,\n> once one commit is marked as still-X (or no-longer-X), that nothing\n> other than the same X is used, and issue an error message, perhaps\n> like this:\n>\n> $ git bisect still-broken v1.6.0\n> $ git bisect still-working v1.8.0\n> error: You earlier marked v1.6.0 as \"still-broken\" and\n> error: are hunting for the first commit that can be marked\n> error: as \"no-longer-broken\". Say either \"still-broken\" or\n> error: \"no-longer-broken\", not \"still-working\".\n>\n> and that can be done without having to understand that \"broken\" is\n> the opposite of \"working\" (of course if we understood that, we could\n> even offer to guess that the user meant \"no-longer-broken\" by\n> \"still-working\", but we do not want to go there).\n\nHere my proposal differs in that I have no way of knowing which label\nis good and which label is bad: I blindly accept two distinct labels\nand bisect with those. I gave an example of this behaviour above.\n"},{"id":"235898","messageId":"xmqqr46jqgfq.fsf@gitster.dls.corp.google.com","threadId":"35956","inReplyTo":"CAL0uuq3eWnLz3=wiexSsJgArUYx95EjLMDWyDvQb9=_ieQUvBA@mail.gmail.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-03T18:34:49Z","receivedAt":"2014-03-03T18:34:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacopo Notarstefano writes:\n\n> Here my proposal differs in that I have no way of knowing which label\n> is good and which label is bad: I blindly accept two distinct labels\n> and bisect with those. I gave an example of this behaviour above.\n\nI think you fundamentally cannot use two labels that are merely\n\"distinct\" and bisect correctly. You need to know which ones\n(i.e. good) are to be excluded and the other (i.e. bad) are to be\nincluded when computing the \"remaining to be tested\" set of commits.\n"},{"id":"236555","messageId":"CAL0uuq0LpQTQPeNVJgKGS2YLTT0gi_BM0wi02c0EP+kvBE4DyA@mail.gmail.com","threadId":"35956","inReplyTo":"xmqqr46jqgfq.fsf@gitster.dls.corp.google.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Jacopo Notarstefano","fromEmail":"jacopo.notarstefano@gmail.com","sentAt":"2014-03-12T01:32:39Z","receivedAt":"2014-03-12T01:32:39Z","isPatch":false,"sender":{"key":"jacopo.notarstefano@gmail.com","avatar":"https://avatars.githubusercontent.com/u/381280?v=4"},"body":"On Mon, Mar 3, 2014 at 7:34 PM, Junio C Hamano wrote:\n> I think you fundamentally cannot use two labels that are merely\n> \"distinct\" and bisect correctly. You need to know which ones\n> (i.e. good) are to be excluded and the other (i.e. bad) are to be\n> included when computing the \"remaining to be tested\" set of commits.\n\nGood point. Yes, this isn't viable.\n"},{"id":"236595","messageId":"xmqqmwgvmfpk.fsf@gitster.dls.corp.google.com","threadId":"35956","inReplyTo":"CAL0uuq0LpQTQPeNVJgKGS2YLTT0gi_BM0wi02c0EP+kvBE4DyA@mail.gmail.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-12T18:31:19Z","receivedAt":"2014-03-12T18:31:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacopo Notarstefano writes:\n\n> On Mon, Mar 3, 2014 at 7:34 PM, Junio C Hamano wrote:\n>> I think you fundamentally cannot use two labels that are merely\n>> \"distinct\" and bisect correctly. You need to know which ones\n>> (i.e. good) are to be excluded and the other (i.e. bad) are to be\n>> included when computing the \"remaining to be tested\" set of commits.\n>\n> Good point. Yes, this isn't viable.\n\nBut if you make them into --no-longer-X vs --still-X, then it will\nbe viable without us knowing what X means.\n"},{"id":"236673","messageId":"5321E8A7.3080907@alum.mit.edu","threadId":"35956","inReplyTo":"xmqqmwgvmfpk.fsf@gitster.dls.corp.google.com","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-03-13T17:19:35Z","receivedAt":"2014-03-13T17:19:35Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/12/2014 07:31 PM, Junio C Hamano wrote:\n> Jacopo Notarstefano writes:\n> \n>> On Mon, Mar 3, 2014 at 7:34 PM, Junio C Hamano wrote:\n>>> I think you fundamentally cannot use two labels that are merely\n>>> \"distinct\" and bisect correctly. You need to know which ones\n>>> (i.e. good) are to be excluded and the other (i.e. bad) are to be\n>>> included when computing the \"remaining to be tested\" set of commits.\n>>\n>> Good point. Yes, this isn't viable.\n> \n> But if you make them into --no-longer-X vs --still-X, then it will\n> be viable without us knowing what X means.\n\nYes, but who wants to type such long and inelegant option names?\n\nIt seems to me that we can infer which mark is which from the normal\nbisect user interaction. At the startup phase of a bisect, there are\nonly three cases:\n\n1. There are fewer than two different types of marks on tested commits.\n For example, maybe one commit has been marked \"bad\". Or two commits\n have both been marked \"slow\". In this case we wait for the user to\n choose another commit manually, so we don't have to know the meaning\n of the mark.\n\n2. There are two different types of marks, but no commits with\n differing marks are ancestors of each other. In this case, we pick\n the merge base of two commits with differing marks and present it\n to the user for testing. But we can do that without knowing which\n mark is \"before the change\" and which mark means \"after the\n change\". So just defer the inference.\n\n3. There are two different types of marks, and a commit with one mark\n is an ancestor of a commit with the other mark. In this case, it is\n clear from the ancestry which mark means \"before the change\" and\n which mark means \"after the change\". So record the \"orientation\" of\n the marks and continue like in the old days.\n\nOf course, there are still details to be worked out, like how to tag the\ncommits before we know which mark means what. But that is just a\nclerical problem, not a fundamental one.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"236681","messageId":"xmqqk3byhr55.fsf@gitster.dls.corp.google.com","threadId":"35956","inReplyTo":"5321E8A7.3080907@alum.mit.edu","subject":"Re: An idea for \"git bisect\" and a GSoC enquiry","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-13T18:47:50Z","receivedAt":"2014-03-13T18:47:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> It seems to me that we can infer which mark is which from the normal\n> bisect user interaction. At the startup phase of a bisect, there are\n> only three cases:\n>\n> 1. There are fewer than two different types of marks on tested commits.\n> For example, maybe one commit has been marked \"bad\". Or two commits\n> have both been marked \"slow\". In this case we wait for the user to\n> choose another commit manually, so we don't have to know the meaning\n> of the mark.\n>\n> 2. There are two different types of marks, but no commits with\n> differing marks are ancestors of each other. In this case, we pick\n> the merge base of two commits with differing marks and present it\n> to the user for testing. But we can do that without knowing which\n> mark is \"before the change\" and which mark means \"after the\n> change\". So just defer the inference.\n>\n> 3. There are two different types of marks, and a commit with one mark\n> is an ancestor of a commit with the other mark. In this case, it is\n> clear from the ancestry which mark means \"before the change\" and\n> which mark means \"after the change\". So record the \"orientation\" of\n> the marks and continue like in the old days.\n>\n> Of course, there are still details to be worked out, like how to tag the\n> commits before we know which mark means what. But that is just a\n> clerical problem, not a fundamental one.\n\nYup, with an extra \"state\" kept somewhere in $GIT_DIR, we should in\nprinciple be able to defer the \"value judgement\" (aka \"which one\nshould be treated as a bottom of the range\").\n\nThe first change that is needed for this scheme to be workable is to\ndecide how we mark such an unknown state at the beginning, though.\nWe assume that we need to keep track of a single top one (\"bad\", aka\n\"no-longer-good\") while we have to keep track of multiple bottom\nones (\"good\").\n\nThere also is a safety valve in the current logic for transitioning\nfrom case #2 to case #3; when a common ancestor is marked as \"bad\"\n(aka \"no-longer-good\"), we notice that the original bisection is\nscrewy in the sense that the user is seeing not just a single state\nflip that made something that used to be good into bad.\n\nI am afraid that we may instead _silently_ decide that the user is\ntrying to locate a state flip that made something that used to be\nbad (at the common ancestor) into good with the logic proposed\nabove. From the point of view of the user who wanted to find a\nregression by marking one as \"bad\" and the other \"good\", running\nbisection whose semantics suddenly and silently changed into an\nopposite \"where was it fixed\" hunt would be an unpleasant and\nconfusing experience. I do not know, without knowing the meaning of\n\"slow\" and \"fast\" (which implicitly tells us which way the user\nintends to bisect), how well we can keep that safety valve.\n\nOther than that, I like the idea.\n"}]}