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