Git 2.56

Every merge conflict ends the same way. You fix the files, and then you have to stage them. And this is exactly the moment when a small accident happens: most of us type git add -u or git add . out of habit. Both commands stage everything that is modified, not only the files you have just resolved. I’ve been bitten by this more than once. A set -x or a debug print in some unrelated file quietly goes into the merge commit together with the resolution. Nobody notices it, because nobody reads merge commits line by line. A few weeks later someone asks why the start script suddenly prints every command. ...

Every few months I run git branch in a repository I work with every day and see a long list: fix-..., add-..., try-.... Most of these branches are pull requests that were merged weeks ago. Git doesn’t delete them by itself, so they just stay there. Until now, I cleaned them up with a one-liner like this: git branch --merged origin/main | grep -vE '^\*|^ *main$' | xargs git branch -d It works, but it’s easy to get wrong. If you forget the grep, main is in the list too. Every branch is compared with the one ref you typed. And there is no way to say “please keep this one”. ...