Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > This reminds me: sometimes people blindly “git pull” a rebased history > just to avoid a non-fast-forward push, and it irks me to no end. So if > I were running the world, the output would be: > > error: rejected non-fast-forward push to '<url>' > hint: To prevent you from losing history, non-fast-forward updates are > hint: rejected by default. > hint: See the 'Note about fast-forwards' section of 'git push --help' > hint: for details. If you were running the world, you'd still need to add stg like YES, I DO MEAN IT, RTFM BEFORE ANYTHING ELSE, AND DON'T COMPLAIN BEFORE YOU REACH THE END OF THE MANPAGE. or so, at least if your friends look like my students ;-) > and the relevant section of the manual would explain that > > 1. if upstream is ahead of you, you may want to "git pull" > > but > > 2. if upstream rebased, you may want to "git pull --rebase", and > yell at upstream a little while at it. > > and > > 3. if the history you are pushing to is both (1) known to be unstable > and (2) wrong, you can override it with > "git push <remote> +<refspec>". Be sure to make sure the > “[receive] denyNonFastForwards” setting is unset correctly in this > case. It's not that far from what the manpage says indeed (it talks about --force instead of +<refspec>, and mentions both pull and pull --rebase). But when the user reached the point where (s)he's wiling to read the doc and finds it interesting, then (s)he'll also read about advice.pushNonFastForward and get rid of the whole (now useless) message ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html