Suggestion for addition to error message upon push to a checked out repository

Suggestion for addition to error message upon push to a checked out repository

[Stephen Holland]

You guys are nice. I’m new to git, just getting a modest personal project big enough to need version control, and a dabbler in Django (which moved to git from Mercurial), so I’m getting into git. The reason I say you’re nice is that on using git I find a number of very helpful comments appearing in my terminal that give rich error messages, instructions and hints on how to proceed. 

In developing my workflow where I can update a server either directly or remotely I came upon the "refusing to update checked out branch: refs/heads/master” error when trying to push changes to the server from remote. Googling shows this error gets asked about a lot. A beginner like me didn't understand that theoretically, since git maintains a graph of changes in the .git directory which could be checked out by anyone, pushes to the .git directory would causes problems down the line if different people could do updates and then try to push them back. (I’m learning, and seeing that git is based on a sound design managed by experienced people). I now see I could have modified a new branch, pushed that, then gone back to the server and merged, but there is another option perfect for my workflow: using the command "git config receive.denyCurrentBranch updateInstead” on the server. 

The updateInstead is documented in 
https://git-scm.com/docs/git-config#Documentation/git-config.txt-receivedenyCurrentBranch
which summarizes this nicely.

My suggestion is that the updateInstead option should be mentioned in the error text that is issued by git after a push that modifies the checked out branch.

For my part, I am a beginner who is living the experience of learning git for the first time. One thing that is missing in the documentation for a beginner is a short introduction to the overall organization of git, what it means for a repository to have been checked out vs bare, and how git works from a hidden directory. I’m willing to contribute such a modest intro, aimed at the beginner to git. 

Should I get into git development to propose this?  Has this been gone over before? What is the process by which suggestions are considered?

My first post, please be gentle.

Stephen Holland, MD
KD4TTC