Re: Newbie grief

    >> This is a very good suggestion.  ...  At least, print a simpler
    >> message with some typical use case causing this and some workflow
    >> ideas before the detailed explanation.

    Junio> It indeed is a good starting point to make a suggestion, but
    Junio> there is nothing actionable in the above by itself,
    Junio> especially since "typical use case" is quite different for
    Junio> different Git users.

Right.

Just add a new git config entry defining "typical use case". :-) And we can recurse to define what is the default value of this and so on... :-)

Just to be constructive, in the previous case, adding something like "It appears that you are trying to push some modifications on a remote server on a branch that has been updated. It may be due to someone having worked on it in the meantime. To go on, you may first do a git merge .... <automatically generated> and try again after solving this so that we are able to precisely track the real history of your project."

The last sentence is to motivate the user to do what may be complicated when coming from, say, SVN, and who do not really care with... real history. ;-)

Well I'm not a native English speaker, but I hope you can get the idea.

After that, there are some other use cases, but I'm not sure that in this case this kind of message would help, because you may have some deeper knowledge of git anyway.

For example for my software testing infrastructure, I push some stuff on some remote git and I force the update of the remote branch anyway with a git push -f. If I forgot the '-f' I would have the same error message above that would not be helpful for me. But anyway, this message is not needed since I use git for my very own specific purpose in this case.