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

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

[Johannes Schindelin]

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

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

[Junio C Hamano]

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

> 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.