I agree to about 70%. 70% of me knows that if that problem is that far behind in the commit history that I have to binary search for it, it might be time to rework my testing methodology. But the other 30% sees how when your team is really big and they all work on the same master, you definitely could make quick work of faulty commits.
@@TesterAnimal1 nah. I mentioned this in another comment. This will only ever be necessary if your dev team is outrageously big and somehow working on one master. Which is quite unusual, in of itself. Obviously if there is a giant makefile tree involved, this might come in handy maybe once in three years. But really not something you should need frequently. If you do, work on the testing strategy, not on finding the errors.
You have probably only worked on smaller projects/teams. If you work with a large team of Devs on a project with hundreds of commits per day, then you WILL use this 100%. I've done the painful manual process described in this video countless times (I'm talking about large projects with MILLIONS of lines of code where it's not uncommon to have less than 100% test coverage for features). I really wish I knew about bisect sooner - for senior developers working on large commercial or government projects, bisect is invaluable to know.
One of the biggest obstacles to Git Bisect is team members with bad Git discipline and make commits that don't build. Last time I used it I had make fixes on a bunch of files, which I then had to undo to continue the bisect. Good Git discipline is important to take advantage of the "extra" features of Git.
In a team setting I like the idea of having PRs as the "unit of change", so in the end you would have your main branch containing squashed commits of working PRs, and could then always utilise a feature like this (at least at the PR level) even if people don't have super clean commits
You can tell bisect to execute that test command for you on each commit and it will work its way through the commits automatically based on whether the command returns an error status (non-zero), which most test runners will do. Check out the “run” sub command. Not sure how one would do that with lazy git, or if it is even possible.
Handy fact: running `git bisect run [command]` will run the giving command then automatically mark a commit as good or bad based on the exit code of the command, and loop accordingly. This command can be a script that includes patching a file with "git apply", although just leaving a file untracked isn't a bad idea
Wow, Lazygit seems nice! I'll have to try that. Also, a good intro to git bisect, and a good tip on how to make a file survive the back-and-forth when bisecting 👍🏼
I just used this a couple of days ago -- went through about 20 commits in a matter of seconds using git bisect run and immediately pinpointed the 5 or so lines of crap I'd written that was causing the problem. Good video. Do another on git bisect run
I had come across this video before and found it cool but didn't think I had much use for it. However, today I was working on a fairly complex PR with lots of changes. Upon pushing the changes to CI, I noticed an unexpected failure. Scanning through the code, it wasn't obvious to me what would be causing the failure, so I remembered the video and decided to try. Thankfully I'm pretty good and strict with breaking down changes into smaller commits which made this process super helpful to spot the exact commit that caused the failure! I think it's funny how so many people here look at this from the perspective of finding bugs in other people's commits, but my experience is proof that it's a valuable tool even in my own personal workflow. My team is also quite good with git history, but even if they weren't, I can still get value from it. Thanks for highlighting how to do it would lazygit btw!
another reason as to why tests should be as simple as possible: the harder the test setup is, the harder it is to make sure it's working hundreds or thousands of commits behind
Main reason why I rarely end up using this in practice is that our CI pipeline just doesn't let anything in unless it passes all reasonably easy to think of bisectable tests, and git log/blame searching is usually enough and better suited for "when was this thing refactored and for what reason" questions. So the only case where I'd think of using it would be if doing debugger traces to find where the call stack changes I guess? Or similar edge cases, that also can't just be solved by understanding the codebase and having CI + monitoring.
I don't find the temporary untracked file approach hacky. I wouldn't know how to do it otherwise. What might be good to add is that you have to install the correct node version and do an npm install as well so you have the correct dependencies available to run the test. Because the bug could also be in the dependencies, in my experience quite often actually.
Ive done this, actually with a script, so it will search automatically with a test. It searched something like 20 commits, it was like magic. Yea, you can run git bisect without needing manual intervention, so its done almost instantly. Of course it was because a coworker kept pushing commits without making sure there was no break or regression, but thats another story.
@@DeadLikeYou how many times that coworkers does that. After the fourth time. I might offer you cold coffee as humoric revenge. Don't break the build. Maybe you should get a hat that says build breaker and ward to the unfortunate dev of the day
Interesting feature, I haven’t encountered that problem since I started to do small feature branches and make sure to never merge with main unless all tests passes.
Depends on the situation, but if something is broken that you know was working before, figuring out what went wrong with a bisect is probably going to be quicker + will give context of why the breaking change was introduced
Ever since I learned about git bisect, I've been amazed at how great it is. The only problem is at my team we squash commits before merging to Dev, so if the bug was created during a big pr, it could still theoretically take a while to figure out why it happened, but it didn't happen to me yet
you should've specified in the title that this is with lazygit and not with the git commands, people might be interested in learning the commands before learning lazygit.
It'd be neat to have a tool to do this automatically. Give it a build+test script and start/end commits, and have it chew away on it to find the commit that fails. Would I ever _use_ that tool? Probably not. I don't think I've ever had a regression that I couldn't track down with Git Blame, so I've never done a binary search like this. But it'd still be neat! (And isn't that half the reason we build anything?)
Unfortunately this feature is not in VSCode's GIT panel. Terminal thing for this will definitely complicates when it's not about just one textual file in a commit.
I'm doing it with Neovim + NeoTree (comes as default with LazyVim) - if you're not interested in vim though you can also split your terminal with just tmux
Cool tool but I never had the issue that i had to search my commit history to find the cause of a regression. Usually I just look at the code and debug it and find the problem.
Learned that 12 years ago, used it twice, thought to myself twice “whoa, I know kung fu” 😂 It’s a cool feature and it’s probably a good sign you almost never need to use it!
Not all my dotfiles but my neovim config is: github.com/joshuamorony/lazyvim/ and I'm using ohmyzsh/powerlevel10k in the terminal, tokyodark theme for neovim
Huh, I just understand the systems I work on so the possible locations of bad code are obvious, then look at history for those few files. This "history first" approach to debugging seems much more tedious.
Hm, I still don't understand what was exact problem that was created that you have to look back through commits? Merge conflict or what? The only real problems outside of breaking git merges with indent (for example in JS/TS) is when for some reason at some time git cannot accept new commits or change branches and throw various errors, in this case I always have to do is copy an entire folder outside, make hard reset in folder, then paste latest content on top of resetted project and readd all changed lines into commit, then push. I couldn't figure out at the time a better solution, but just resetting everything definitely sold it.
It's not for fixing Git issues, you can use it to track down any kind of regression in the codebase. My example was over simplified and you probably wouldn't need bisect to find it, but I introduced a commit where the "add" function was modified to subtract numbers. Somehow this commit makes it through to prod, and a while later someone notices that numbers aren't being added correctly. Rather than manually finding where the bug was introduced (although it would be trivial in this case), you can use bisect to find the commit that caused the functionality to break automatically.
He said he's using lazygit which is an open-source 3rd party terminal UI for Git. You just install that and run lazygit command, but you don't have to use it to do bisect commands.
If you can find the bug, there’s almost always no point finding the commit lol. The whole point of this flow is to try to get a starting point for a complicated bug that’s hard to localize to one place.
Next newsletter goes out tomorrow with an extra merge conflict tip: mobirony.ck.page/4a331b9076
Love that. I will never use it.
Same
I agree to about 70%. 70% of me knows that if that problem is that far behind in the commit history that I have to binary search for it, it might be time to rework my testing methodology.
But the other 30% sees how when your team is really big and they all work on the same master, you definitely could make quick work of faulty commits.
You will.
@@TesterAnimal1 nah. I mentioned this in another comment. This will only ever be necessary if your dev team is outrageously big and somehow working on one master. Which is quite unusual, in of itself.
Obviously if there is a giant makefile tree involved, this might come in handy maybe once in three years. But really not something you should need frequently. If you do, work on the testing strategy, not on finding the errors.
You have probably only worked on smaller projects/teams. If you work with a large team of Devs on a project with hundreds of commits per day, then you WILL use this 100%.
I've done the painful manual process described in this video countless times (I'm talking about large projects with MILLIONS of lines of code where it's not uncommon to have less than 100% test coverage for features).
I really wish I knew about bisect sooner - for senior developers working on large commercial or government projects, bisect is invaluable to know.
One of the biggest obstacles to Git Bisect is team members with bad Git discipline and make commits that don't build. Last time I used it I had make fixes on a bunch of files, which I then had to undo to continue the bisect. Good Git discipline is important to take advantage of the "extra" features of Git.
In a team setting I like the idea of having PRs as the "unit of change", so in the end you would have your main branch containing squashed commits of working PRs, and could then always utilise a feature like this (at least at the PR level) even if people don't have super clean commits
Squashed PRs for the win
Yep, I like this too. Squashed PR, fast-forward merge only.
@@hundvd_7does "squashed" mean merge but storing only first parent in commit header?
if others push bad commits, they should prepare for a force push
You can tell bisect to execute that test command for you on each commit and it will work its way through the commits automatically based on whether the command returns an error status (non-zero), which most test runners will do. Check out the “run” sub command. Not sure how one would do that with lazy git, or if it is even possible.
Came to say this. You can automate bisecting and it's almost instant to find the problem.
Handy fact: running `git bisect run [command]` will run the giving command then automatically mark a commit as good or bad based on the exit code of the command, and loop accordingly. This command can be a script that includes patching a file with "git apply", although just leaving a file untracked isn't a bad idea
Thanks. There is also the "git bisect run" command to run the tests (check and continue the bisect as needed)
This. I expected him to say "and this is what git bisect run is for, so we can automate this step too"
I would honestly consider reuploading the vid with this additional tip to make it complete.
That makes it a hell of a lot more useful and automated.
Wow, Lazygit seems nice! I'll have to try that.
Also, a good intro to git bisect, and a good tip on how to make a file survive the back-and-forth when bisecting 👍🏼
I just used this a couple of days ago -- went through about 20 commits in a matter of seconds using git bisect run and immediately pinpointed the 5 or so lines of crap I'd written that was causing the problem. Good video. Do another on git bisect run
Great audio quality. Excellent video quality. Interesting "CLI" topic. Subscribed.
I had come across this video before and found it cool but didn't think I had much use for it. However, today I was working on a fairly complex PR with lots of changes. Upon pushing the changes to CI, I noticed an unexpected failure. Scanning through the code, it wasn't obvious to me what would be causing the failure, so I remembered the video and decided to try. Thankfully I'm pretty good and strict with breaking down changes into smaller commits which made this process super helpful to spot the exact commit that caused the failure!
I think it's funny how so many people here look at this from the perspective of finding bugs in other people's commits, but my experience is proof that it's a valuable tool even in my own personal workflow. My team is also quite good with git history, but even if they weren't, I can still get value from it.
Thanks for highlighting how to do it would lazygit btw!
another reason as to why tests should be as simple as possible: the harder the test setup is, the harder it is to make sure it's working hundreds or thousands of commits behind
Damn, definitely need more of this content around here. I use lazygit regularly, but still haven't use most of the feature. Thanks man!
The untracked file trick is a solution I've been looking for for a long time now. Thanks!
Main reason why I rarely end up using this in practice is that our CI pipeline just doesn't let anything in unless it passes all reasonably easy to think of bisectable tests, and git log/blame searching is usually enough and better suited for "when was this thing refactored and for what reason" questions.
So the only case where I'd think of using it would be if doing debugger traces to find where the call stack changes I guess? Or similar edge cases, that also can't just be solved by understanding the codebase and having CI + monitoring.
I have done this sooo many times, yet it is still so rare that my biggest challenge is going to be remembering this is a thing.
Rather than pop the stash, you could also apply it so that the stashed changes don't get removed every time.
Good suggestion
thia was really helpful actually. thanks for sharing.
geeat summary - I didn't know about this but will be keeping it in the back pocket. Thanks
I don't find the temporary untracked file approach hacky. I wouldn't know how to do it otherwise.
What might be good to add is that you have to install the correct node version and do an npm install as well so you have the correct dependencies available to run the test. Because the bug could also be in the dependencies, in my experience quite often actually.
hello docker , hello can you here me, does the container have reception, hello can you,
ahhh docker daemon is out of coverage area
@@elmalleable What are you on?
@@JoepKockelkorn hmmm good question. What's your guess?
Ive done this, actually with a script, so it will search automatically with a test. It searched something like 20 commits, it was like magic. Yea, you can run git bisect without needing manual intervention, so its done almost instantly.
Of course it was because a coworker kept pushing commits without making sure there was no break or regression, but thats another story.
@@DeadLikeYou how many times that coworkers does that. After the fourth time. I might offer you cold coffee as humoric revenge. Don't break the build.
Maybe you should get a hat that says build breaker and ward to the unfortunate dev of the day
Nice tutorial! I'm now into lazygit because of this video xD
I really like the untracked temp file, idk why I hadn't thought of that before
Interesting feature, I haven’t encountered that problem since I started to do small feature branches and make sure to never merge with main unless all tests passes.
Whats that TUI IDE you are using in your terminal
@@gamertechkid1490 it's neovim/lazyvim
"when things break, I do a binary search of git".
Really? I usually debug the error. D:
Am I doing it wrong?
Depends on the situation, but if something is broken that you know was working before, figuring out what went wrong with a bisect is probably going to be quicker + will give context of why the breaking change was introduced
Last time I used git bisect for a benchmark I fixed and found out it regressed since it was broken 4 years prior.
Lazygit is the best. Thanks for this video!
It would be really fun if bisect feature is appended with a way to hookup a test and auto execute.
Ever since I learned about git bisect, I've been amazed at how great it is.
The only problem is at my team we squash commits before merging to Dev, so if the bug was created during a big pr, it could still theoretically take a while to figure out why it happened, but it didn't happen to me yet
@@ARKGAMING big pr, easy, full revert the offending commit, even if full of other things. Yes, I hate squash commits... :)
just get the pr branch and bisect that :p
@@partywumpus5267 we delete merged branches so no can do
you should've specified in the title that this is with lazygit and not with the git commands, people might be interested in learning the commands before learning lazygit.
I always keep an untracked folder in all my projects specifically to have cross versions files for quick stupid testing.
It'd be neat to have a tool to do this automatically. Give it a build+test script and start/end commits, and have it chew away on it to find the commit that fails.
Would I ever _use_ that tool? Probably not. I don't think I've ever had a regression that I couldn't track down with Git Blame, so I've never done a binary search like this. But it'd still be neat! (And isn't that half the reason we build anything?)
You can also use stash and apply the stash with the test
Unfortunately this feature is not in VSCode's GIT panel. Terminal thing for this will definitely complicates when it's not about just one textual file in a commit.
Which font is that
i use it, it's amazing
🔥
hi would you tell that what is the name of this module that can split the terminal into directories and file contents?
I'm doing it with Neovim + NeoTree (comes as default with LazyVim) - if you're not interested in vim though you can also split your terminal with just tmux
@@JoshuaMorony thank you!
Could you please also share your beautiful nvim setup. Please 🙏
Sure, it's public here: github.com/joshuamorony/lazyvim/
Tnx for the tip with new untracked test file
What do you use in your terminal? Is that tmux?
Yes, this is ohmyzsh/powerlevel10k/tmux/neovim
🔥🔥🔥
Cool tool but I never had the issue that i had to search my commit history to find the cause of a regression. Usually I just look at the code and debug it and find the problem.
Learned that 12 years ago, used it twice, thought to myself twice “whoa, I know kung fu” 😂
It’s a cool feature and it’s probably a good sign you almost never need to use it!
Read that as Git Biscuit.
I like your setup! Are your dot files public? Theme?
Not all my dotfiles but my neovim config is: github.com/joshuamorony/lazyvim/ and I'm using ohmyzsh/powerlevel10k in the terminal, tokyodark theme for neovim
I never, ever searched through commits this way.
GOAT!
Hey! Another JM in software engineering! What it do 😁
One more thing to complicate my full devstack life with.
Unfortunately for big projects that are building for a long time. Bisect is not the best option otherwise it's a neat tool!
It's trying to solve a problem which wasn't a problem in the first place.
love lazygit now even mroe
Pretty much binary search. Cool
Dividing the interval in haly to find something Foster. Thats exactly is bisect.😊
git blame: "am i a ***king joke for you?"
Huh, I just understand the systems I work on so the possible locations of bad code are obvious, then look at history for those few files. This "history first" approach to debugging seems much more tedious.
What VSCode theme are you using?
I'm using neovim with the tokyodark theme
I just start up the debugger and fix the issue. Not hard, even on a repo with millions of lines
this platform has a lot of shitpost but this video is up there amongst the best
Wait until he discovers git blame 😂
Well, the Good news is if Kim Kardashian uses the same half-half approach sooner or later will choose me for her next husband! 😂😂😂
Hm, I still don't understand what was exact problem that was created that you have to look back through commits? Merge conflict or what? The only real problems outside of breaking git merges with indent (for example in JS/TS) is when for some reason at some time git cannot accept new commits or change branches and throw various errors, in this case I always have to do is copy an entire folder outside, make hard reset in folder, then paste latest content on top of resetted project and readd all changed lines into commit, then push. I couldn't figure out at the time a better solution, but just resetting everything definitely sold it.
It's not for fixing Git issues, you can use it to track down any kind of regression in the codebase. My example was over simplified and you probably wouldn't need bisect to find it, but I introduced a commit where the "add" function was modified to subtract numbers. Somehow this commit makes it through to prod, and a while later someone notices that numbers aren't being added correctly. Rather than manually finding where the bug was introduced (although it would be trivial in this case), you can use bisect to find the commit that caused the functionality to break automatically.
Aaaaah, if you had just followed TDD ... 😂
why not git blame on the line of the bug?
Sometime you don’t know where is the bug but you can git show the commit that introduces the bug to check it after you find it with bisect
Easy?
Ah yes, Minesweeper but for git.
don't need it. just git gud
love how you didn't show how to make the screen you're looking at appear.
He said he's using lazygit which is an open-source 3rd party terminal UI for Git. You just install that and run lazygit command, but you don't have to use it to do bisect commands.
nice
I've done this with checkout once, wish I knew this feature
No, i do not see this usefull at all. Usually some of the last commits are the source of the problem. Never done bisection in my life.
Or, with a real IDE you find the bug, you select the bug, and you do a "git show history"
A real ide like VIM
Real IDE like… the toy that is VS Code?
If you can find the bug, there’s almost always no point finding the commit lol.
The whole point of this flow is to try to get a starting point for a complicated bug that’s hard to localize to one place.