Re: Feature idea: Git hook for pre-checkout

>
> "brian m. carlson" <sandals@crustytoothpaste.net> 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@gitster.siamese.dyndns.org/
> is one of them.