Re: [RFC PATCH 0/2] MVP implementation of remote-suggested hooks

[Junio C Hamano <gitster@pobox.com>]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> If we do add this feature (which, as I said, I'm opposed to) and we
> decide to store it in a ref, that ref should not be a normal branch by
> default (it should be a special one-level ref, like refs/stash or such),
> and the ref name should be configurable.  Not all developers use English
> as their working language and we should respect that.

Just this part.

I am not sure what you are trying to achieve by requiring it to be
configurable.  After all, even for names of branches that are used
to store the code, which is of more significance than this "unusual"
ref, we've lived with a hardcoded 'master' and with the server-end
advertisability of the configured values (i.e. "git clone" was
designed to figure out if the origin used a custom name for the
primary line of history and use the same name from the beginning),
the end-user sitting on the receiving end did not have to do
anything special even when the project wanted to use a custom name.

But this "unusual" ref would not have a natural equivalent of "the
origin side can point the primary branch with its HEAD", so by
allowing it to be configurable, you are pretty much closing the door
for those who blindly honor whatever the origin tells them to use
when running "git clone" from doing so.  I agree that it is a good
security measure (and I am not sold to the "remote suggested hooks"
idea in the first place), but is that the real reason why you
suggested configurability?