git/list[1] front-page[2] threads[3] people[4] search[5] about
 

git bisect problems/ideas

From
Aaron S. Meurer <asmeurer@gmail.com>
Date
Jan 15, 2011, 07:33 UTC
Message-ID
<855249CA-A006-475C-8F96-EFD614795064@gmail.com>
First off, do you guys have an issue tracker?  I asked on IRC, and someone told me that he didn't think you did, and to just post here.  After searching your websites, as far as I can tell he was right, though this is amazing to me that you can handle a project like this without an issue tracker.  If you guys really do, then sorry.  I would rather post this there than here (though if you really do, please make it more findable!)
I just noticed this error/bug:

git checkout test git bisect start <do some bisecting> git branch -D test <finish bisecting> git bisect reset

And it gives an error, because test has been deleted.  This is in 1.7.3.5.  Now, I looked through the log of the current master of git to see if anything has been done about this, and all I noticed was the commit 3bb8cf88247db5, which essentially improves the error message.  
Now, this is good, because it seemed to me above that I was stuck bisecting until I recreated the test branch.  I did not realize the git bisect <commit> syntax until later.  
But this has brought me to bother you guys about something that has been bugging me for a while. I hate git bisect reset.  90% of the time I do not want to go back to where I started bisecting.  I would much prefer to just have a git bisect stop command, which just stops the bisecting process, but leaves me where I am (like a shortcut to git bisect reset HEAD).  This would be much more symmetric with git bisect start.
While we are on the topic of bisecting, I have another issue.  Can we remove the restriction that a "bad" commit come after a "good" commit?  I'd say about 70% of the time I use bisect to find a commit that fixes a bug, not breaks it.  Whenever this happens, I have to bend my mind over backwards to remind myself that the good behavior is really "bad" and the bad behavior is really "good".  Is there a reason that git bisect can't just introspect from which comes earlier and which comes later to see which is "good" or "bad" (instead of just raising an error when they are in the "wrong" order)?
Aaron Meurer
Next: Christian Couder
Message 1 of 17 in “git bisect problems/ideas”
  1. Aaron S. MeurerJan 15, 2011
  2. Christian CouderJan 17, 2011
  3. Jonathan NiederJan 17, 2011
  4. SZEDER GáborJan 17, 2011
  5. Jonathan NiederJan 17, 2011
  6. Christian CouderJan 18, 2011
  7. Aaron S. MeurerJan 17, 2011
  8. Aaron S. MeurerJan 17, 2011
  9. Christian CouderJan 18, 2011
  10. Junio C HamanoJan 18, 2011
  11. Christian CouderJan 19, 2011
  12. Aaron S. MeurerJan 19, 2011
  13. Junio C HamanoJan 19, 2011
  14. Aaron S. MeurerJan 19, 2011
  15. Christian CouderJan 21, 2011
  16. Johannes SixtJan 21, 2011
  17. Jakub NarebskiJan 22, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.