5 ms·
Do people really use bisect in their professional life? Can you sensibly use it without an enforcement of every PR being squashed, as otherwise you have not wo
by thealistra 2y ago
Do people really use bisect in their professional life?
Can you sensibly use it without an enforcement of every PR being squashed, as otherwise you have not working, half baked commits all the time while bisecting? And you can’t compile, not even saying about stating if your bug is still reproducible or not.
- saghm 2y agoYeah, I've used it a bunch. No project I've ever worked on has made it a practice to merge not working, half-baked commits at all. Squashing before merging like you mention has been pretty much universal on the codebases I've worked on; if it's not done on a given PR, it's usually because of an explicit rebase to split things up manually in a way that wouldn't break this.
- univerio 2y agoYes! But for me it's very rare (< 1/yr) and I'm like a kid in a toy store every time I get to bust it out. My employer uses squash commits so that's not a problem for us, but you're right that commits far enough back will be unlikely to be in a buildable state.
- CJefferson 2y agoIt depends on your type of software. I use it all the time for mathematical software. I have an input I keep around, which checks "is the program, very basically, doing what it should?", which is compatible with all previous versions. I use that when to 'git bisect skip' commits which don't build, or if when built aren't functioning at all. It's not 100% perfect, but works well for me.
- smcameron 2y ago> PR being squashed, as otherwise you have not working, half baked commits squashing PRs is not the only way to avoid broken half-baked commits. Use something like stgit and it's easy to create a stream of 100s of commits that all work and make sense without squashing any commits together. I used git bisect yesterday.
- winternewt 2y agoCan stgit patches be pushed to a private branch on a central remote like GitHub or Bitbucket in case you need to work on the stack from multiple computers?
- kevincox 2y agoYes. It is very helpful for seeing what change introduced a bug to help understand why it happened, what could be undone by simple fixes and what assumptions were broken. If you use a simple merging workflow --first-parent can avoid testing inside feature branches if you find they are commonly broken. You can also just skip broken commits if they are rare. Also I thought git bisect prefered testing merges before inside the merged branch, but I can't find official documentation in this on my phone. Either way I have never seen this to be much of a problem. (Including in nixpkgs which merges branches every which way)
- deleted 2y ago[deleted]
- cryptonector 2y ago> Do people really use bisect in their professional life? Yes. > Can you sensibly use it without an enforcement of every PR being squashed, [...] I insist on linear, clean history, i.e., rebase workflows. No merge turds.
- noahwhygodwhy 2y agoYeah, we enforce squash merges and it works pretty well
- happytoexplain 2y agoYes, I use it rarely, but regularly. It is simply the fastest way to discover when a behavior was introduced. I'm not sure what un-squashed PRs have to do with half-baked commits. Inexperienced devs tend to make too few commits, not too many. I've never known anybody to make commits that don't compile except by a rare accident. It's one of the few rules of version control that people tend to obey without having to make an effort to change their existing habits.
- AlotOfReading 2y agoNon-compiling intermediate commits is basically the normal workflow for most people I've reviewed, unless they're rewriting history. One commit will do something like refactor an interface, the next will modify a distinct subset of callers, etc. Sometimes those intermediates don't compile for any number of reasons. I'll personally rewrite history for teams that want clean commits, but definitely not universally. How do you develop that you don't have broken intermediate working states or thoughts that you can't complete by the end of the day?
- NoahKAndrews 2y agoI commit a WIP commit, and amend it the next day
- basil-rash 2y agoYou in fact do not need to commit at the end of the day. You can just… wait until the work is done.
- yarg 2y agoOr, just create a feature branch, commit as you go, squashing before you merge.
- AlotOfReading 2y agoYou can wait, but why would you? Your intermediate work doesn't have to be clean and it's occasionally nice to have a "reset everything to this morning" button without digging into reflog.
- andreareina 2y agogit bisect now has a --first-parent option, so as long as every merge builds and passes tests, what's going on in the branches is fine. And yeah, I use it all the time. https://git-scm.com/docs/git-bisect https://git-scm.com/docs/git-bisect
- dullcrisp 2y agoYes of course, every commit on your main branch should pass CI.
- cryptonector 2y ago> Yes of course, every commit on your main branch should pass CI. Or when you fix a bug first you put the regression test in a new commit first then the fix, that way you can show that a) the test finds the bug that is b) fixed by the subsequent commit. This means you need to git bisect skip such commits, but that's fine.
- jsmeaton 2y agoEven better, if your testing framework supports it, mark the test as expecting failure in your regression commit, then remove the xfail in the commit that fixes the bug.
- MBlume 2y agoI actually prefer to add a passing test asserting the bug exists in one commit, then fix the bug and reverse the sense of the test in a second commit. The second commit is now more or less self documenting -- this case used to produce this buggy behavior but now produces correct behavior -- and the fact that the test originally passed provides proof that the test is capable of detecting a regression.
- david_allison 2y agoPut the failing test into the codebase with an `@Ignore`, have the second commit remove the `@Ignore`
- jononor 2y agoAt least every merge point. That is easy to enforce with GitHub/Gitlab etc. Is there a way for git bisect to only try those commits?
- foobiekr 2y agoYes. Not everyone likes squashed/rebase workflows and it's frustrating to have to police people. A lot of groups use a workflow where all commits to branches of global interest are strictly pull requests. For those who are in this situation, consider that what you can do is test _only_ merge commits - that is, put something like this into a script: if git log -1 --pretty=%B | grep -q 'Merge pull request'; then # tests here exec the_actual_test.sh else exit 125 fi ... then "git bisect run script.sh". This skips the intermediates and only tests merge waypoints. Edit: someone below notes --first-parent option, which basically accomplishes the same thing.
- RexM 2y agoNot often, but it’s been helpful to find non-obvious causes of bugs.
- GrantMoyer 2y agoYou can report a commit as good, bad, or unkown (`git bisect skip`), and git bisect will do "the right thing", even for non-linear histories. You can also automatically report un-testable commits during `git bisect run`. Of course, you may end up with a range of commits where a regression was introduced rather than a specific commit.
- winternewt 2y agoWhy are you commiting things that do not compile or pass tests to a shared branch? Git is not your backup solution.
- plugin-baby 2y ago> Git is not your backup solution. Yes it is. What am I doing wrong?
- harperlee 2y agoWell, sharing it on a common branch with others. Share finished bits of work that help others; keep the snapshot of your messy workshop with the table full of things and tools on a private branch.
- winternewt 2y agoGit is for 1. Helping with conflict resolution when multiple people work on a piece of code, and 2. Tracking changes to software over time, to aid in bug fixing, patching older versions, and understanding why the code looks the way it does. If you're intentionally committing code that doesn't work then you are ruining both the ability for others to work with the code, and your own ability to use the history for anything. You _can_ use it as a poor man's backup solution (I do this myself), but the key then is to have a clear separation between a "work in progress" branch that only you work in, and the collaborative or long-lived branches. Before you merge a work-in-progress branch (or make a pull request), you need to make sure that each commit that remains passes the unit tests. You can use an interactive rebase for this.
- kevincox 2y agoThe problem with Git is that it is actually a rich man's backup solution. It lets you do very detailed snapshotting and manipulation across versions. So when working on something it can be very helpful to have many commits during the work. But I agree that it is usually best to then "refine" those into nice, working, logical chunks before sharing with others.
- 2y ago
- david_allison 2y agoUsed it yesterday You train people/enforce in CI that all commits on `main` compile. People shouldn't not be committing broken code. Squash if they can't manage that. 1) You can `skip` a bad commit if it happens 2) You can branch and rebase a unit test into the history to use a scripted bisect run
- growse 2y agoI'm interested in #2 here - I've often struggled with writing a test to identify a bug, and then using that new test with bisect to find the commit where that test would first fail. Has this technique got a googlable name?
- david_allison 2y agoNo googleable name. I think the following is enough to explain the concept. It's not quite how I do things, but it's mostly right https://www.pauline-vos.nl/fix-bugs-%E2%9A%A1-fast-with-regression-tests-and-auto-bisect/ https://www.pauline-vos.nl/fix-bugs-%E2%9A%A1-fast-with-regr...
- growse 2y agoThanks- commit then rebase reorder is a simple but great idea!
- morgante 2y agoYes, I use it pretty regularly when I encounter a regression. I generally mandate linear history for repos and squash all commits. I've frankly never understood people who don't.