The first one isn't criticizing the lack of ability to set default pull behavior, it's criticizing that if you try to set an alias overriding a built-in command, it fails silently, instead of giving any indication that your alias doesn't work.
Basically all the criticisms in Git Koans still apply.
I just always rebase :shrug:
In that case, you can use: `git config -global pull.rebase true`
After that, `git pull` will automatically attempt to rebase your local commits on top of new commits pulled from a remote, so you don’t even have to do it manually.
(I still do it manually, though, because I’m a little bit paranoid about my version control and prefer to do my merges/rebases explicitly, with a lot of extra testing and inspection. Though obviously that won’t work for everyone in every codebase!)
What I'd really like, is something in-between auto-rebase and ff-only: automatically try to "re-arrange" my commits and the upstream's commits so that they apply cleanly, but if there isn't a way to do that, then just refuse to do anything, rather than putting me in conflict-edit "both modified" mode.
Sounds fair, though you should be able to `git rebase --abort` when you get into that mode so it's not a huge deal. (I'm not 100% sure since I almost never use `git pull`; I almost always `git fetch`.)
I can see how a "rebase with auto-abort" would be helpful in some situations, though.
For example, in regards to the first one (someone wanting pulls to fail if they’d trigger a merge instead of doing the merge automatically), modern git now gives you an option to enforce that restriction explicitly: `git config -global pull.ff only`, rather than trying to hack the behaviour together via an alias.
Modern git is actually pretty pushy about that particular setting, these days! Until you’ve configured how you want to handle pulls, it pesters you to specify which pulling behaviour you want every time you pull changes into any repo from anywhere!