4 ms·

Git bisect. For certain classes of software regressions, it makes life easier. Many people (me) don’t know this feature exists and end up reinventing the wheel

Git bisect. For certain classes of software regressions, it makes life easier. Many people (me) don’t know this feature exists and end up reinventing the wheel on their own. https://git-scm.com/docs/git-bisect https://git-scm.com/docs/git-bisect

benreesman 1y ago
And interactive rebase. Master interactive rebase and reflog until you can do it blindfolded.
- lanfeust6 1y ago
  Agreed with interactive rebase, but what of reflog? I've checked that for commit hashes when things have gone very wrong but I don't know many commands.
  - benreesman 1y ago
    It allows you to observe and interact with the history of refs like HEAD, so superficially destructive operations like amending a commit can be recovered, reverted, etc. It's kind of like meta-git, allowing version control operations on the version control system. It's a lifesaver when you botch a merge or something and allows you to do "destructive" operations fearlessly (up to a point, you can munge a git repo pretty bad if you try hard enough).
- pseudo_meta 1y ago
  I've only used reflog really to look up a hash and reset back to it. Is there anything else about it one should learn?
- Cthulhu_ 1y ago
  Interactive rebase is something I use a lot, but I should look into improving its ergonomics; sometimes I just want to apply the current changes to a previous commit. I did have a shortcut / script the one time but it was very finnicky and fragile.
  - dancek 1y ago
    https://github.com/mystor/git-revise https://github.com/mystor/git-revise is great for just this. Of course there's also `git commit --fixup=<commit>` and `git rebase --autosquash` if you don't want to install extra software. But the ergonomics of `git revise` are better. I've also tried git-absorb before. It was buggy at least back then. Uninstalled when it crashed and lost my changes, and even reflog didn't help.
lanfeust6 1y ago
Very useful. What we always say after the fact is "we need more tests".
sureglymop 1y ago
Similar feelings about git worktree. Being able to check out multiple branches at once without having to deal with stash is a game changer.
koolba 1y ago
Whenever people try to argue that small and meaningful commits do not matter, I introduce them to git bisect. I’ve yet to meet someone familiar with it that does not agree.
- sethammons 1y ago
  I have used git bisect twice in 15 years and seen it used maybe three other times. I have burned hours upon hours on rebase conflicts over the years. I have settled on squash merging feature branches into main and no force pushes on anything shared, ever.
  - koolba 1y ago
    > I have burned hours upon hours on rebase conflicts over the years. Hate to say, "You're using it wrong", but if you haven't repeated conflicts rebasing, then your commits are probably just not small enough. A merge does not magically eliminate any of the conflicts either, you just do them all at once rather than point by point. And the smaller the changeset, the less likely you will have any conflict at all. Small changes, sorted lists (so parallel additions rarely conflict), allowing trailing commas (again to allow for parallel addition), splitting dependency updates from structural changes (to allow wholesale removing them if they were done separately), ... there's plenty of little changes to how you put together work that make this workflow easier.
    - ubercow13 1y ago
      Is this true? If the upstream changes some lines of code once, but your branch changes them 5 times in separate commits, iterating on the correct change to those lines, you will have to resolve conflicts 5 times. And 4 of those times you'll be expending effort to merge the correct code from upstream with code you know isn't correct/final on your branch. Likewise if multiple iterations on those lines were made upstream while your feature branch exists. Fundamentally expending any effort to find a coherent combination of two pieces of code where one of them you know isn't going to remain is a waste of time. The only advantage would be if those incremental changes actually make it easier to arrive at the final merge of the last changes on each branch but I'm not sure your above tips really guarantee that. IME it rarely happens.
alper 1y ago
The amount of times I've used `git bisect` productively can be counted on one hand.
apples_oranges 1y ago
It's a useful tool, but sort of a tool of last resort.

benreesman 1y ago

And interactive rebase. Master interactive rebase and reflog until you can do it blindfolded.

lanfeust6 1y ago
Agreed with interactive rebase, but what of reflog? I've checked that for commit hashes when things have gone very wrong but I don't know many commands.
- benreesman 1y ago
  It allows you to observe and interact with the history of refs like HEAD, so superficially destructive operations like amending a commit can be recovered, reverted, etc. It's kind of like meta-git, allowing version control operations on the version control system. It's a lifesaver when you botch a merge or something and allows you to do "destructive" operations fearlessly (up to a point, you can munge a git repo pretty bad if you try hard enough).
pseudo_meta 1y ago
I've only used reflog really to look up a hash and reset back to it. Is there anything else about it one should learn?
Cthulhu_ 1y ago
Interactive rebase is something I use a lot, but I should look into improving its ergonomics; sometimes I just want to apply the current changes to a previous commit. I did have a shortcut / script the one time but it was very finnicky and fragile.
- dancek 1y ago
  https://github.com/mystor/git-revise https://github.com/mystor/git-revise is great for just this. Of course there's also `git commit --fixup=<commit>` and `git rebase --autosquash` if you don't want to install extra software. But the ergonomics of `git revise` are better. I've also tried git-absorb before. It was buggy at least back then. Uninstalled when it crashed and lost my changes, and even reflog didn't help.

lanfeust6 1y ago

Very useful. What we always say after the fact is "we need more tests".

sureglymop 1y ago

Similar feelings about git worktree. Being able to check out multiple branches at once without having to deal with stash is a game changer.

koolba 1y ago

Whenever people try to argue that small and meaningful commits do not matter, I introduce them to git bisect. I’ve yet to meet someone familiar with it that does not agree.

sethammons 1y ago
I have used git bisect twice in 15 years and seen it used maybe three other times. I have burned hours upon hours on rebase conflicts over the years. I have settled on squash merging feature branches into main and no force pushes on anything shared, ever.
- koolba 1y ago
  > I have burned hours upon hours on rebase conflicts over the years. Hate to say, "You're using it wrong", but if you haven't repeated conflicts rebasing, then your commits are probably just not small enough. A merge does not magically eliminate any of the conflicts either, you just do them all at once rather than point by point. And the smaller the changeset, the less likely you will have any conflict at all. Small changes, sorted lists (so parallel additions rarely conflict), allowing trailing commas (again to allow for parallel addition), splitting dependency updates from structural changes (to allow wholesale removing them if they were done separately), ... there's plenty of little changes to how you put together work that make this workflow easier.
  - ubercow13 1y ago
    Is this true? If the upstream changes some lines of code once, but your branch changes them 5 times in separate commits, iterating on the correct change to those lines, you will have to resolve conflicts 5 times. And 4 of those times you'll be expending effort to merge the correct code from upstream with code you know isn't correct/final on your branch. Likewise if multiple iterations on those lines were made upstream while your feature branch exists. Fundamentally expending any effort to find a coherent combination of two pieces of code where one of them you know isn't going to remain is a waste of time. The only advantage would be if those incremental changes actually make it easier to arrive at the final merge of the last changes on each branch but I'm not sure your above tips really guarantee that. IME it rarely happens.

alper 1y ago

The amount of times I've used `git bisect` productively can be counted on one hand.

apples_oranges 1y ago

It's a useful tool, but sort of a tool of last resort.