"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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?
