3 ms·

Sometimes the scaffolding should be left in place to help show others how to build things; other times, it was put up and taken down so many times that the lear

Sometimes the scaffolding should be left in place to help show others how to build things; other times, it was put up and taken down so many times that the learning from the first few attempts isn't worth it. I would probably be much happier not squashing stuff if you were able to bisect cleanly to points between branch merges. I don't think that's even theoretically possible; which means that when you're bisecting it's quite possible to pick up half-baked mid-branch points that you have to recognise for the broken rubbish they are - lots of false positives there occasionally, and makes bisect a lot less useful. On a repo with nice squashed commits, you tend to be able to narrow down to the feature very quickly - of course those commits then tend to be bigger etc., but I find that less of an issue.

WorldMaker 11y ago
Maybe bisect needs a flag like --start-with-merges to focus it's efforts on -no-ff merges? Also, what if there was a tool on top of bisect that could better utilize GitHub PR JSON to target the search pattern? That could even save you some time in the case where you already have CI information attached to your PRs...
- stormbrew 11y ago
  There was a patch submitted in 2011[1] to do roughly that, but it got diverted into a different purpose and then seems to have disappeared. It certainly seems like it must be possible to have a git-bisect that can deal with branches. [1] http://git.661346.n2.nabble.com/RFC-Add-bad-branch-first-option-for-git-bisect-td5954008.html http://git.661346.n2.nabble.com/RFC-Add-bad-branch-first-opt...