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 <gitster@xxxxxxxxx> wrote: > > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > > > On 2025-01-29 at 10:49:15, Mike Weltevrede wrote: > >> 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. > > > 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@xxxxxxxxxxxxxxxxxxxxxxxxxx/ > is one of them.
