To push into a non-bare repository, or not to push into it...

Johannes Schindelin· Nov 29, 2007, 01:33 UTC · lore

Hi,

how about resolving this recurring subject of discussion by introducing a config variable, say "branch.allowPushingIntoHEAD". We'd teach git-init to set it to "false", and receive-pack would refuse to update HEAD if it is "false", _unless_ core.bare = true.

Of course, we would default the value to "false" to leave existing setups functional.

However, if it is "true" (and core.bare is not true) -- which would need user interaction to explicitely set it -- receive-pack would also make sure that the working tree is clean (locking the index for the complete operation), and call "read-tree -u -m HEAD" in the end.

By refusing the update we would be able to give users a severe *WARNING*, but a hint how to put their HEAD in the noose.

I'd do a patch, but I am 1) tired, and 2) more thinking about that git-repack enhancement for repo.or.cz.

Ciao, Dscho

Junio C Hamano· Dec 1, 2007, 02:37 UTC · re: Johannes Schindelin · lore

Re: To push into a non-bare repository, or not to push into it...

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 7 quoted lines

> how about resolving this recurring subject of discussion by introducing a 
> config variable, say "branch.allowPushingIntoHEAD".  We'd teach git-init 
> to set it to "false", and receive-pack would refuse to update HEAD if it 
> is "false", _unless_ core.bare = true.
>
> Of course, we would default the value to "false" to leave existing setups 
> functional.

Perhaps that could be a reasonable compromise, except that it does not feel right to assume that new repositories are used by new users. People who have been been trained to expect "git push" to checked out branches always work (and they know "git reset --hard" or have equivalent post-update hook) will wonder why their push into a new clone does not work while their push into existing ones does.

But with a good diagnosis to pushers when receive-pack refuses a push for this reason, I do not think that should be too much of a problem.

Upon REF_STATUS_REMOTE_REJECT, the message on "ng " line will be given by send-pack to the pusher, so the infrastructure to do so is already there, I think. We need to utilize it when we implement your suggestion.