Hi all,

Thanks for your swift and elaborate response. I think that those are a
very clear explanation and it makes sense to me to take a look into
the alternatives you propose.


Kind regards,

Mike Weltevrede

On Thu, 30 Jan 2025 at 18:25, Junio C Hamano [off-list ref] wrote:

"brian m. carlson" [off-list ref] writes:

quoted

On 2025-01-29 at 10:49:15, Mike Weltevrede wrote:

quoted

Good morning,

I had an idea for a feature in Git. I am not sure if this is the
correct channel, but I could not find anything else. If not, could you
please let me know the best way to submit this?

This is the appropriate place to make feature requests.

Yes, indeed.

quoted

I don't think this is likely to be adopted.  We intentionally don't
place a lot of restrictions on local actions, ...
In addition, this change wouldn't really be very effective, ...
`git push origin my-feature:refs/features/foo`.
It also sounds like you're trying to implement a policy decision on the
local system, which is the wrong place, as the Git FAQ outlines[0]:

Thanks for raising all good points.

Even though I am negative on adding a hook that does not satisify
any of the "5 valid reasons" [*], this one squarely satisifies (1).
But I fully agree with you that it is ineffective as a policy
enforcement mechanism, and a local hook should not be used as such.

Having said that, giving reminders locally and early to help users
avoid making mistakes that will be pointed out at the remote at
reception time via their pre-receive hook, only when the user does
"git push", can still be a good friction reducer.

So I am not opposed to an idea to have a mechanism that reminds the
users of project-specific naming convention of branches and files
(think: cross platform projects that have participants from case
insensitive filesystems) when they create such a thing anew locally,
especially the project would have a rejection mechanism when their
participants try to push their changes that adds such a thing.

Here, however, again I agree with you that a pre-checkout hook will
not be an effective mechanism to give that reminder.  The mechanism
must sit at the ref API layer in order to vet all ways of creating
(or renaming) a ref in order for to be effectively restrict branch
names.  For pathnames, the mechanism must sit at the cache API layer
to tell add_to_index() what names are problematic.

Thanks.


[Reference]

*1* There may be slightly updated versions of this in the archive, but
https://lore.kernel.org/git/7vbq7ibxhh.fsf@gitster.siamese.dyndns.org/ (local)
is one of them.