git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Mike Weltevrede <mikeweltevrede@gmail.com>,  git@vger.kernel.org
Subject: Re: Feature idea: Git hook for pre-checkout
Date: Thu, 30 Jan 2025 09:25:46 -0800	[thread overview]
Message-ID: <xmqqy0ysfc2t.fsf@gitster.g> (raw)
In-Reply-To: <Z5rhXrkbhINwFDXT@tapette.crustytoothpaste.net> (brian m. carlson's message of "Thu, 30 Jan 2025 02:18:06 +0000")

"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.

  parent reply	other threads:[~2025-01-30 17:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-29 10:49 Feature idea: Git hook for pre-checkout Mike Weltevrede
2025-01-30  2:18 ` brian m. carlson
2025-01-30 14:11   ` Konstantin Khomoutov
2025-01-30 17:25   ` Junio C Hamano [this message]
2025-02-01 10:09     ` Mike Weltevrede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqy0ysfc2t.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mikeweltevrede@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).