I swear to god, If I have to explain git bisect to another "senior" one more time!! Like, how do you _not_ know this?! Know your basics, please! 🤬

I don't know what git bisect is and I have to google it. Then again I am a junior.

After googling it, seems like it's a fancier way to debug bad commit. I usually just use git checkout <hash>

You should know how to pick your battles

When someone comes to me unaware of something.. I have two choices. Either tell em to google it and explain it right away. I choose the first one most of the time. Let them figure it out on their own.

Try having to explain the importance of single responsibility principle <i>to the head of the engineering department</i> while they try and rip into your (test driven) code.

Background:
If you didn't know that's the very first letter in SOLID.
The head of engineering was a dev for a few years before getting promoted
The managers and senior devs liked my code and I got praise for it.

Utter 🤡

I don't see the problem, to be honest. Not like a 3min websearch will show you what it is and how to use it. It is very rarely that you need such a feature in the first place, at least for me. When was the last time you have to go back and test which commit caused something? If you do it a lot, it means either your git commit messages aren't good, your code is not explained enough / hard to understand or you don't understand the code very well. It is also a sign that there is not enough testing.

I wouldn't consider it a basic. I need about 100 git commands per day, mostly status, diff, add, log, commit and push. Last time i needed to search for a commit that introduced a new bug and blame and log couldn't find it was at least 2 months ago (more likely i needed this 2 times per year). Or about 1in 4000 or less (more like 1 in 12'000) git commands. And even then, it is questionable if bisect is really the best option instead of 2-3 manual checkouts (most of the time, the amount of git commits to consider isn't larger than 10).

All in all, it is a command that is useful for about 1 in about 10'000 - 24'000 git commands or something you need once ever 2-6 months.

git bisect is only useful with an automated pipeline / script / ...

Pipeline as in: clean, build, run specific testcase.

Depending on the project, this can be one hell of hail mary - especially if there is no specific test case as one does not even know what the problem is, for example mysterious runtime behaviour, increase of memory usage for unknown time, ...

If one has an automated pipeline, yeah - git bisect can be great.

If not, it's too much work to be honest, especially if the test case cannot be automated / is unclear.

I never needed a feature like bisect. Might come in handy for that one-in-a-million mystery bug occuring every time but still being hard to find though. Didn't stumble upon such a bug yet. But who knows...

Never used it. Clone, push, pull, add, stash, rebase, and commit are my friends

whats git bisect? 🤣

I never had to use it

@iceb

Simply put, an interactive way to test all commits in a range.

Let's say :
Commit 1 is the last deployed version.
Commit 20 is the current deployed version.

Deployed version has a bug.

How to find the git commit that introduced the bug?

That's what git bisect does.

You can e.g. just say
git bisect <Commit 1> <Commit 20>

Now bisect will start, checkout each commit revision in this range, ask for each commit if the commit was "good" or "bad" (these terms can be changed).

So one can narrow down which commit introduced faulty behaviour, aka the first bad commit.

Git bisect can additionally run a script that automates the interactive part - so one could do a kind of "git powered bug hunter".

Git bisect has additional features, like narrowing down the range to a know directory | file automatically (so the full range will be automatically reduced to only commits having changes regarding that file)… going back and forward N commits in the range ... Etc.

It's very nifty if there is an automatic pipeline available.

That's how e.g. the kernel / test farms narrow down faulty behaviour in thousands of commits...

@IntrusionCM As far as i know, git bisect doesn't check out each commit but does a binary search. The name comes from there: Check out the middle commit of the list, determine if it the bug/feature is in that commit and split the in half and repeat.

@IntrusionCM if you had an automated pipeline, you would have caught the bad commit already

@happygimp0
I simplified it, cause my explain mode is always for stupid people... Kinda scary that I expect a dev to not know what a binary search is, but hey... Intelligent devs are rare. :-) ;)

@electrineer

That's only true if the pipeline contains a test / check that can spot the regression...

Another dumb feature of a dumb rcs