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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux