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