ok you all have convinced me to write a bonus page about git bisect, but I'm going to need some help because I very very rarely use git bisect!
-
ok you all have convinced me to write a bonus page about git bisect, but I'm going to need some help because I very very rarely use git bisect!
gonna put a couple of polls in this thread, starting with: when you use git bisect, what command do you run? (you can pick more than one)
-
if you use git bisect: would you say the repositories you use bisect on have a "clean" git history?
(i'm trying to understand to what extent a "clean" git history is necessary when using bisect)
-
if you use git bisect, do you usually use it to find
-
A general regression. Not necessarily a bug.
-
@Foxboron what's an example of a regression that isn't a bug?
-
@b0rk
Whether or not something *is* a bug is determined after you figure out the regression.Something that used to work, now it doesn't.
It might be intentional, it might be a bug.
-
@b0rk
I can't come up with a good example right now. I don't bisect stuff that often -
@b0rk when you're on a team doing lots of releases, it doesn't matter who's commit it is. You're looking for the commit in the release that introduced a bug or a regression.
-
@polotek huh i'd never thought of bisect as being related to release management, that makes a lot of sense
-
@polotek also do you have an example of a regression that isn't a bug? i'm struggling to understand the difference a bit
-
@b0rk Your poll mentions performance regression. I was trying to include things like that.
-
@Foxboron @b0rk a performance or memory usage regression, perhaps. Such as a new field added to a struct that changed the cache line layout, pushing apart two fields that are frequently used together. Or a new security check that should have been zero cost but ended up impacting certain workloads. Or an optimization for one workload that accidentally pessimized another. Or using a new compiler feature, that ends up being unexpectedly buggy in older versions of gcc.
-
@b0rk @polotek agreed with this. Bisect works far better in repos where the trunk is mostly always clean (e.g. squashed merges with good DoD discipline || fast forward merges with an excellent PR hygiene).
It tends to break a bit when teams do "red commit [adding a test] / "add feature, back to green" / "refactor, make it clean" commits and leave them all the way to trunk, as there will be false "bad" builds. Solution in that case is to manually shift by a few commits up or down in the log and try again; hence doing bisects manually.
-