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.

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.

> 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.

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.

i can count maybe 3 times in the last 15 years ive used git bisect and it didnt even catch the bug in at least one of those cases.

It's one of those things that sounds super cool and advanced and i thought id be using all the time when i first learned about it but in practice 99/100 times to see when and where to bug was introduced it it's quicker and easier to just track it down manually in the code.

On the other side of experiences - i have used git bisect at least 3 times just last week to track down source of regression. I was not the person who wrote the code originally or introduced the regression. All i knew that it worked in last version but not now. Bisect, do an easy fix, add the missing test and move on to next bug. No need to think hard.

I suspect it depends highly on the size of the code, number of commits, number of committers, etc; I can imagine it can be very useful in e.g. Linux when you're trying to find when something was introduced when that may have been 15 years ago in a piece of code touched by hundreds of people / thousands of commits since then.

Even when the bisect points to a large commit, it's usually not too difficult to find the source of the regression. Sometimes I've had to go into the original PR and bisect on its commits which is a bit harder. It doesn't seem worth it to me to try to maintain commit quality within a PR when as long as I commit often enough it doesn't really make a difference.

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

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

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.

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).

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?

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.

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.

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

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

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