Comment by jerf

Comment by jerf 6 days ago

20 replies

View on Hacker News

"git bisect" is why I maintain the discipline that all commits to the "real" branch, however you define that term, should all individually build and pass all (known-at-the-time) tests and generally be deployable in the sense that they would "work" to the best of your knowledge, even if you do not actually want to deploy that literal release. I use this as my #1 principle, above "I should be able to see every keystroke ever written" or "I want every last 'Fixes.' commit" that is sometimes advocated for here, because those principles make bisect useless.

The thing is, I don't even bisect that often... the discipline necessary to maintain that in your source code heavily overlaps with the disciplines to prevent code regression and bugs in the first place, but when I do finally use it, it can pay for itself in literally one shot once a year, because we get bisect out for the biggest, most mysterious bugs, the ones that I know from experience can involve devs staring at code for potentially weeks, and while I'm yet to have a bisect that points at a one-line commit, I've definitely had it hand us multiple-day's-worth of clue in one shot.

If I was maintaining that discipline just for bisect we might quibble with the cost/benefits, but since there's a lot of other reasons to maintain that discipline anyhow, it's a big win for those sorts of disciplines.

aag 6 days ago

Sometimes you'll find a repo where that isn't true. Fortunately, git bisect has a way to deal with failed builds, etc: three-value logic. The test program that git bisect runs can return an exit value that means that the failure didn't happen, a different value that means that it did, or a third that means that it neither failed nor succeeded. I wrote up an example here:

https://speechcode.com/blog/git-bisect

Reply View 1 reply
SoftTalker 6 days ago

I do bisecting almost as a last resort. I've used it when all else fails only a few times. Especially as I've never worked on code where it was very easy to just build and deploy a working debug system from a random past commit.

Edit to add: I will study old diffs when there is a bug, particularly for bugs that seem correlated with a new release. Asking "what has changed since this used to work?" often leads to an obvious cause or at least helps narrow where to look. Also asking the person who made those changes for help looking at the bug can be useful, as the code may be more fresh in their mind than in yours.

Reply View 0 replies
forrestthewoods 6 days ago

> why I maintain the discipline that all commits to the "real" branch, however you define that term, should all individually build and pass all (known-at-the-time) tests and generally be deployable in the sense that they would "work" to the best of your knowledge, even if you do not actually want to deploy that literal release

You’re spot on.

However it’s clearly a missing feature that Git/Mercurial can’t tag diffs as “passes” or “bisectsble”.

This is especially annoying when you want to merge a stack of commits and the top passes all tests but the middle does not. It’s a monumental and valueless waste of time to fix the middle of the stack. But it’s required if you want to maintain bisectability.

It’s very annoying and wasteful. :(

Reply View 14 replies
  • michalsustr 6 days ago

    This is why we use squash like here https://docs.gitlab.com/ee/user/project/merge_requests/squas...

    Reply View 10 replies
    • snowfarthing 6 days ago

      As someone who doesn't like to see history lost via "rebase" and "squashing" branches, I have had to think through some of these things, since my personal preferences are often trampled on by company policy.

      I have only been in one place where "rebase" is used regularly, and now that I'm a little more familiar with it, I don't mind using it to bring in changes from a parent branch into a working branch, if the working branch hasn't been pushed to origin. It still weirds me out somewhat, and I don't see why a simple merge can't just be the preferred way.-

      I have, however, seen "squashing" regularly (and my current position uses it as well as rebasing) -- and I don't particularly like it, because sometimes I put in notes and trials that get "lost" as the task progresses, but nonetheless might be helpful for future work. While it's often standard to delete "squashed" branches, I cannot help but think that, for history-minded folks like me, a good compromise would be to "squash and keep" -- so that the individual commits don't pollute the parent branch, while the details are kept around for anyone needing to review them.

      Having said that, I've never been in a position where I felt like I need to "forcibly" push for my preferences. I just figure I might as well just "go with the flow", even if a tiny bit of me dies every time I squash or rebase something, or delete a branch upon merging!

      Reply View 3 replies
      • Izkata 5 days ago

        > I cannot help but think that, for history-minded folks like me, a good compromise would be to "squash and keep" -- so that the individual commits don't pollute the parent branch, while the details are kept around for anyone needing to review them.

        But not linked together and those "closed" branches are mixed in with the current ones.

        Instead, try out "git merge --no-ff" to merge back into master (forcing a merge commit to exist even if a fast-forward was possible) and "git log --first-parent" to only look at those merge commits. Kinda squash-like, but with all the commits still there.

        Reply View 0 replies
      • rlkf 5 days ago

        I use git-format-patch to create a list of diffs for the individual commits before the branch gets squashed, and tuck them away in a private directory. Several times have I gone back to peek at those lists to understand my own thoughts later.

        Reply View 0 replies
      • r-bryan 5 days ago

        Well dang, we are not restricted to git as the only place we can put historical metadata. You know, discursive comments, for starters?

        Reply View 0 replies
    • forrestthewoods 6 days ago

      I explicitly don’t want squash. The commits are still worth keeping separate. There’s lots of distinct pieces of work. But sometimes you break something and fix it later. Or you add something new but support different environments/platforms later.

      Reply View 4 replies
      • gregthelaw 5 days ago

        But if you don't squash, doesn't this render git bisect almost useless?

        I think every commit that gets merged to main should be an atomic believed-to-work thing. Not only does this make bisect way more effective, but it's a much better narrative for others to read. You should write code to be as readable by others as possible, and your git history likewise.

        Reply View 3 replies
    • badmintonbaseba 5 days ago

      git bisect supports --first-parent, no need to squash if you just merge.

      Reply View 0 replies
  • Izkata 6 days ago

    If there's a way to identify those incomplete commits, git bisect does support "skip" - a commit that's neither good nor bad, just ignored.

    Reply View 1 reply
    • JetSetIlly 5 days ago

      Can we use git trailers for this? Something like "commit: incomplete" in the commit message.

      Reply View 0 replies
  • rlkf 5 days ago

    Could you not use --first-parent option to test only at the merge-points?

    Reply View 0 replies
skydhash 6 days ago

Same. Every branch apart from the “real” one and release snapshots is transient and WIP. They don’t get merged back unless tests pass.

Reply View 0 replies