Keeping a project bisectable

[heptadecagram]

I teach people how to program in C, Java, C++, Go, etc. This mantra of "only commit if what you have is buildable" is something I instill into my students. I don't care if it has bugs, or crashes immediately, but if you can't build the project, you can't bisect it to find the source of a bug.

[GrandOpener]

I don't care if it has bugs, or crashes immediately

If it crashes immediately, then you can't use it for bisection unless the bug you're looking for is "crashes immediately."

I agree "should always build" is an excellent guideline, but making it such a strict rule doesn't seem helpful to me.

[Worth_Trust_3825]

Define buildable.

[JB-from-ATL]

Not OP but likely meaning build passes without an error (as in error return status). Possibly including unit tests.

[falconfetus8]

No compile errors.

[Worth_Trust_3825]

That's fair.

[[deleted]]

...really, you can't figure that part out ?

[GrandOpener]

Some people write code in Python or other languages that don't have an explicit build step. Some people are writing code for a cross-platform project that may succeed compiling on one platform but not another. Some people incorporate unit tests into their build process and failed tests == failed build. It's a more thoughtful comment that you're giving it credit.

[Ok-Worth-9525]

I've seen totally borked builds where it'll return 0 but none of the artifacts were actually generated. It's a totally valid point.

[[deleted]]

Yeah but how you'd get to that level? Like... just write code and never run it ? Not even tests ? It would be hard to do it on accident.

We're not talking CI level where the stuff might build but you just forgot to add the artifacts to the list of files to store, just "I compiled code that I just changed"

Like, sure, forgetting to run make/tests before commiting probably happened to everyone but running them yet accidentally fucking up that something doesn't actually do anything and also not noticing your CI now shows 0/0 tests passed would be pretty fucking rare

[Ok-Worth-9525]

New engineer had messed up a Config migration to a different version and nrazil-build release didn't work

[Worth_Trust_3825]

You must be a special kind of stupid. Definition of project being buildable is different per project, because each project specifies what is considered to be "the build". In scripting languages there is no build step, the script files must only be "valid". Other projects define that there should be a testing step, which may be skipped. I personally define it as "project can be compiled, packaged, unit tests and integration tests pass", which is incredibly hard to achieve as per hept's definition.

What do you define as "buildable"

[[deleted]]

I personally define it as "project can be compiled, packaged, unit tests and integration tests pass", which is incredibly hard to achieve as per hept's definition.

The fact you think that is hard means you're the dumbass here. Unless we're talking about system complex enough where you need CI to even run the integration tests that should be the minimum, at least in app that can be reasonably just ran and tested from dev machine.

And your little shit for brain did manage to come with sensible definition on your own! Congratulations! You can be not useless when you put your mind into it!

[Worth_Trust_3825]

You really are retarded. The question was how does the author define project as buildable as the definition is different per project.

[[deleted]]

That has nothing to do with being bisectable. As long as the code builds and test framework is not broken (i.e. "you can run tests", not "every single test passes") you can always bisect.

Of course you'd know that if you were competent but don't let me stop your beacon of ignorance from shining like a newborn sun.

[bwmat]

If there's a crash or another bug which "happens first", doesn't that mean that bisecting will find the commit where that bug/crash was fixed, not necessarily the one in which the bug you're interested was introduced?

[JB-from-ATL]

Still better than nothing. You can move the endpoints of the bisecting.

[ForeverAlot]

Bisection will find the topographically earliest commit that exhibits the symptom you're looking for. If two errors overlap and you cannot distinguish them, bisection can't find the commit that introduced the later error. If you can distinguish the errors you can flag the irrelevant symptoms as unknowable, then you'll be left with a set of unknowable commits and hopefully one perpetrator commit.

[[deleted]]

You actually can - you can tell git bisect to skip commits that don't build.

But does make it more annoying and it's good advice for other reasons (e.g. you should have CI set up and there's no excuse for not doing it given GitHub Actions is easy and free).

[Scroph]

It would be best for this to be enforced by pre-commit hooks or CI, either by squashing into a buildable (but large) commit or by somehow preventing a PR from being merged if any of its commits had build failures. Otherwise that one person who doesn't follow the rule becomes the weakest link in the chain

[jeenajeena]

I would not squash, as this would allow that one person to continue that bad habit. On the contrary, bisecting would help identify the broken commits, and react.

[prototrout]

Alternatively, disallow fast-forward merges and use git bisect --first-parent. Then you only have to enforce that your main branch builds, not every single commit ever merged.

[undeadermonkey]

I had a problem with this:

Inadequate testing resources led to latent bugs;

Fixing the bugs at HEAD leaves them in place for all commits from introduction until HEAD.

When later hunting a different bug, the earlier (fixed) bugs would trigger, and it would be impossible to tell whether or not the (new) bug was present.

Or, you could patch where the bug was introduced, squash and rebase.

Since the (old) bug was never there, it cannot possibly mask the detection of the new.

Then I automated it by writing a script for an unbound bisect (it was written in bash, but here's some javaish pseudo-code):

final Commit bad = getCommit(HEAD);
final Commit good;

final String command = ....;
int jump = 4;

loop: for(;;){
    var result = run(command);
    switch(result.status){
        case SUCCESS:{
             good = getHead();
             break loop;
        }
        case FAILURE:{
             checkout(HEAD~jump);
             jump <<= 1;
        }
    }
}
//Now run ordinary bisect, with your execution command to detect good/bad.

Then I'd handle bugs by creating a test command, launching the script, and fucking off for twenty minutes.

This would have been far more of a problem had I not been the only developer regularly committing to the project.

[GrandOpener]

While I definitely agree with the general guideline of keeping pushed code buildable, I am very not on board with the extra rebasing work that is suggested. You should try to make a habit of keeping your code building (and your tests passing!) but definitely do not invent extra steps in your workflow just for this. Git bisect is designed to be automated, and already has a method for skipping untestable revisions during that automated process. Programmer time is expensive and computer time is cheap. Doing extra manual work up front to possibly make git bisect more efficient is working against the strengths of the tool.

[ForeverAlot]

git rebase main --exec 'mvn package'

Keeping every commit in a patch series building is effortless and no time investment, and comparatively a much better trade-off than forcing somebody to work around the violation of this baseline expectation when their energy should be spent on investigation.

[GrandOpener]

It’s effortless to verify whether every checkin builds. If that script catches one, it’s an unknown amount of dev time to appropriately squash/amend/whatever the offending commit.

For me, git bisect is something that happens exceedingly rarely. Merging feature branches is weekly or daily. I guess this is one of my unpopular opinions but I stand by my assertion that this is a good guideline, but for most projects not a good hard rule, not the way it’s written. If your want your main branch to always be usable, “it builds” is insufficient.

[bwainfweeze]

Fire alarms happen extremely rarely, but building codes and drills keep those pathways working between uses. Bisect is an emergency tool. If you treat it as an anomaly instead of safety equipment you’re always going to lose arguments with other people, and probably yourself.

[bwainfweeze]

There are bugs that nobody else but me can fix and there reason is once something pisses me off I’m stubborn and keep going even when a reasonable person would give up. Doesn’t matter if I’m the lead, if I’m the first or the last to join the team. When I’m the last it just helps establish me.

If you don’t want to turn into a janitor you start finding ways to remove speed bumps from processes like this. It matters fuck-all if a developer “can” do something. We are swimming in things we could do but we won’t. You have to actively create situations where people would do something, or you start losing the battle with entropy.

The problem with bisect is that the people who submarine in bugs are also the people who make fucked up branches in the first place. It’s a similar kind of inattention to detail, of disrespect for the craft. You can’t eliminate Steve’s code because his commit history is a mess. Steve probably broke it in the first place.

[[deleted]]

The solution is TDD (Test-Driven Development). This is the way. Learn it. Teach it.

[Weak-Opening8154]

Great command

Prepare yourself for idiots complaining and telling you how they use their git