My struggles with git have been well documented. One thing I didn’t touch on is its tendency to suddenly change the behaviour of core commands from release to release. I’ve got used, over the last months, to seeing this:
mike@thor:~/git/other/kindle-backup$ git push
warning: push.default is unset; its implicit value is changing in
Git 2.0 from ‘matching’ to ‘simple’. To squelch this message
and maintain the current behavior after the default changes, use:
git config –global push.default matching
To squelch this message and adopt the new behaviour now, use:
git config –global push.default simple
When push.default is set to ‘matching’, git will push local branches
to the remote branches that already exist with the same name.
In Git 2.0, Git will default to the more conservative ‘simple’
behavior, which only pushes the current branch to the corresponding
remote branch that ‘git pull’ uses to update the current branch.
See ‘git help config’ and search for ‘push.default’ for further information.
(the ‘simple’ mode was introduced in Git 1.7.11. Use the similar mode
‘current’ instead of ‘simple’ if you sometimes use older versions of Git)
But today I saw this as well:
mike@thor:~/git/other/kindle-backup$ git add .
warning: You ran ‘git add’ with neither ‘-A (–all)’ or ‘–ignore-removal’,
whose behaviour will change in Git 2.0 with respect to paths you removed.
Paths like ‘documents/._pg10554.mobi’ that are
removed from your working tree are ignored with this version of Git.
* ‘git add –ignore-removal ‘, which is the current default,
ignores paths you removed from your working tree.
* ‘git add –all ‘ will let you also record the removals.
Run ‘git status’ to check the paths you removed from your working tree.
What the hell, git? This is simply not the way rational software behaves. I don’t get in my car and find a message saying “for your convenience, the functions of the accelerator and brake pedals have been swapped”.