On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > I don't understand the benefit of adding a new command "mark" rather > than continuing to use "good", "bad", plus new commands "unfixed" and > "fixed". Does this solve any problems? > As Matthieu Moy remarked in a previous email, the main reason is extensibility: I prefer having a single command to assign new descriptive labels instead of having to patch git-bisect.sh to create new labels like fixed, unfixed, fast, slow... > What happens if the user mixes, say, "good" and "fixed" in a single > bisect session? > I don't think that's an issue. If the user uses the label "fixed" instead of "bad" she will have a hard time remembering to use it every time she needs it, and maybe the output of "git bisect" will look very confusing, but what can git do? This is a semantic user input error, not a syntax one. > I think it would be more convenient if "git bisect" would autodetect > whether the history went from "good" to "bad" or vice versa. The > algorithm could be: > > 1. Wait until the user has marked one commit "bad" and one commit "good". > > 2. If a "good" commit is an ancestor of a "bad" one, then "git bisect" > should announce "I will now look for the first bad commit". If > reversed, then announce "I will now look for the first good commit". If > neither commit is an ancestor of the other, then explain the situation > and ask the user to run "git bisect find-first-bad" or "git bisect > find-first-good" or to mark another commit "bad" or "good". > > 3. If the user marks another commit, go back to step 2, also doing a > consistency check to make sure that all of the ancestry relationships go > in a consistent direction. > > 4. After the direction is clear, the old bisect algorithm can be used > (though taking account of the direction). Obviously a lot of the output > would have to be adjusted, as would the way that a bisect is visualized. > > I can't think of any fundamental problems with a scheme like this, and I > think it would be easier to use than the unfixed/fixed scheme. But that > is only my opinion; other opinions are undoubtedly available :-) > I like this idea! It also looks fun to implement. A minor difference is that I'd rather die with an error on point 2) if there's no ancestorship relation between the two commits; if the user is asking for such a thing then she has a fundamental misconception of the state of her repository. > By the way, although "git bisect fixed/unfixed" would be a very useful > improvement, and has gone unimplemented for a lamentably long time, my > personal feeling is that it has too meat in it to constitute a GSoC > project by itself. Oh! Then in fact, as Christian Couder said, this project shouldn't be marked as "easy". (Sorry for sending this email twice! I thought I had sent it to the list as well.) On Thu, Feb 27, 2014 at 12:18 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > On 02/26/2014 09:28 AM, Jacopo Notarstefano wrote: >> my name is Jacopo, a student developer from Italy, and I'm interested >> in applying to this years' Google Summer of Code. I set my eyes on the >> project called "git-bisect improvements", in particular the subtask >> about swapping the "good" and "bad" labels when looking for a >> bug-fixing release. > > Hello and welcome! > >> I have a very simple proposal for that: add a new "mark" subcommand. >> Here is an example of how it should work: >> >> 1) A developer wants to find in which commit a past regression was >> fixed. She start bisecting as usual with "git bisect start". >> 2) The current HEAD has the bugfix, so she marks it as fixed with "git >> bisect mark fixed". >> 3) She knows that HEAD~100 had the regression, so she marks it as >> unfixed with "git bisect mark unfixed". >> 4) Now that git knows what the two labels are, it starts bisecting as usual. >> >> For compatibility with already written scripts, "git bisect good" and >> "git bisect bad" will alias to "git bisect mark good" and "git bisect >> mark bad" respectively. >> >> Does this make sense? Did I overlook some details? > > I don't understand the benefit of adding a new command "mark" rather > than continuing to use "good", "bad", plus new commands "unfixed" and > "fixed". Does this solve any problems? > > What happens if the user mixes, say, "good" and "fixed" in a single > bisect session? > > I think it would be more convenient if "git bisect" would autodetect > whether the history went from "good" to "bad" or vice versa. The > algorithm could be: > > 1. Wait until the user has marked one commit "bad" and one commit "good". > > 2. If a "good" commit is an ancestor of a "bad" one, then "git bisect" > should announce "I will now look for the first bad commit". If > reversed, then announce "I will now look for the first good commit". If > neither commit is an ancestor of the other, then explain the situation > and ask the user to run "git bisect find-first-bad" or "git bisect > find-first-good" or to mark another commit "bad" or "good". > > 3. If the user marks another commit, go back to step 2, also doing a > consistency check to make sure that all of the ancestry relationships go > in a consistent direction. > > 4. After the direction is clear, the old bisect algorithm can be used > (though taking account of the direction). Obviously a lot of the output > would have to be adjusted, as would the way that a bisect is visualized. > > I can't think of any fundamental problems with a scheme like this, and I > think it would be easier to use than the unfixed/fixed scheme. But that > is only my opinion; other opinions are undoubtedly available :-) > >> There were already several proposals on this topic, among which those >> listed at https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed. >> I'm interested in contacting the prospective mentor, Christian Couder, >> to go over these. What's the proper way to ask for an introduction? I >> tried asking on IRC, but had no success. > > Just CC Christian on your emails to the mailing list, like I've done > with this email. As a rule of thumb all communications should go to the > mailing list *plus* any people who are likely to be personally > interested in the topic (e.g., because they have participated in the > thread). > > By the way, although "git bisect fixed/unfixed" would be a very useful > improvement, and has gone unimplemented for a lamentably long time, my > personal feeling is that it has too meat in it to constitute a GSoC > project by itself. > > Michael > > -- > Michael Haggerty > mhagger@xxxxxxxxxxxx > http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html