3 ms·
I think, though, that for "never loses changes" to be meaningful it has to be shorthand for "never loses changes unless you do unsafe things". I mean, it certai
by sgentle 16y ago
I think, though, that for "never loses changes" to be meaningful it has to be shorthand for "never loses changes unless you do unsafe things". I mean, it certainly loses changes if you don't push to anywhere and then delete your .git directory.
The -f should mean "don't do this, it will probably wreck your shit". Unfortunately certain tools seem to require it way too often so it seems to be going the way of the venerable confirm dialog.
"Deleted all my files? I dunno, some funny box popped up and I hit OK. Was that it?"
- azernik 16y agoThis user training gets even worse because git, when refusing to perform an unsafe operation, trains the user to force instead of training the user to fix the problem. For example, the developer who overwrote the commits in the case in question probably did so after seeing the following error message: abort: push creates new remote heads on branch 'default'! (did you forget to merge? use push -f to force) While it mentions merging, the only recognizable command line ("push -f") is for a destructive operation, instead of the operation (pull or merge, depending on the situation) that will actually fix the unsafe condition. Putting an even partial command line in front of a developer is like putting an OK button in front of a non-technical user - they tend to just use it to see if it (superficially) works. When it (subtly) fails, a novice user will not notice, and will just remember "push -f" as the Right Way to Use Git.
- fr0sty 16y agoThat appears to be an hg error message. The git version is: $ git push github master To git@gitproxy:rip747/ cfwheels.git ! [rejected] master -> master (non-fast forward) error: failed to push some refs to ‘git@gitproxy:rip747/cfwheels.git’ That makes no mention of -f (or any git commands at all).