4 ms·
Yes, git bisect is the way to go: in addition to the stuff you mentioned, his method only dives into one parent branch of merge commits. git bisect handles that
by OskarS 5y ago
Yes, git bisect is the way to go: in addition to the stuff you mentioned, his method only dives into one parent branch of merge commits. git bisect handles that correctly. A gem of a tool, git bisect.
- ljm 5y agoBisect also does a binary search so if you're looking for one bad commit amongst many others, you'll find it much more quickly than linearly testing commits, one at a time, until you find a working one.
- randomopining 5y agoHow does bisect help in a large project? Seems like it would be best to use personal expertise to find it
- matt_kantor 5y agoI've only used bisect a handful of times, but I think it can be most useful in large projects with many contributors. In smaller projects you can spot a bug and often surmise "I bet this is related to Fred's pull request yesterday that updated the Foo module", but in a larger repository where you don't have all the recent history in your head you might not even know where to start looking. In such cases being able to binary search through history is handy.
- deleted 5y ago[deleted]
- ljm 5y agoThis is a hilariously absurd proposition. The existence of `git bisect` necessarily precludes an issue that personal expertise cannot find without some help. Personal expertise tells you to use a tool like git bisect to find a problem, so you are more effective in your work. The same as it tells you to use gdb to debug a stack trace. Or do you eyeball the CPU executing instructions in realtime? An absence of personal expertise will convince you that you are smart enough to do it on your own.
- randomopining 5y agoSo let’s say there’s 50 commits in a short time between good and bad. Of those 50 there’s a few that are “maybes”. Bisect is completely useless