{"thread":{"id":"62868","subject":"Feature idea: Git hook for pre-checkout","startedAt":"2025-01-29T10:49:28Z","lastAt":"2025-02-01T10:09:36Z","messageCount":5,"participants":["Mike Weltevrede","brian m. carlson","Konstantin Khomoutov","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"511404","messageId":"CAAE-bwUQ+0ERbvC=SS=-R_K4H3p2su+=Ogf7BSkyq5J4GmmRYw@mail.gmail.com","threadId":"62868","inReplyTo":null,"subject":"Feature idea: Git hook for pre-checkout","fromName":"Mike Weltevrede","fromEmail":"mikeweltevrede@gmail.com","sentAt":"2025-01-29T10:49:15Z","receivedAt":"2025-01-29T10:49:28Z","isPatch":false,"sender":{"key":"mikeweltevrede@gmail.com","avatar":null},"body":"Good morning,\n\nI had an idea for a feature in Git. I am not sure if this is the\ncorrect channel, but I could not find anything else. If not, could you\nplease let me know the best way to submit this?\n\nBelow, I will explain the idea and then the problem that this would solve.\n\n<The idea>\nI have a project that is using Git hooks. Besides pre-commit and\npre-push, I would like to use pre-checkout (rather than the already\navailable post-checkout). However, it seems like an active choice not\nto have pre-checkout given the existing hooks, so I am curious as to\nthe reason behind this.\n\n<The problem>\nI want to do branch name validation when someone does git checkout -b.\nIf the branch name does not meet the requirements, the user should not\nbe allowed to checkout to it. As such, the post-checkout hook does not\nfully meet my needs. It helps with doing the branch name validation,\nbut if it fails, the user is still on the feature branch. As such, if\nthey are ignorant about the error message, this does not stop them. I\nam currently combining post-checkout and pre-push but would prefer\npre-checkout because this would prevent the user from doing work on\nthis feature branch and having to move their work.\n\n\nI am looking forward to your thoughts. Thank you for your consideration.\n\n\nMet vriendelijke groet / Kind regards,\n\nMike Weltevrede\n"},{"id":"511449","messageId":"Z5rhXrkbhINwFDXT@tapette.crustytoothpaste.net","threadId":"62868","inReplyTo":"CAAE-bwUQ+0ERbvC=SS=-R_K4H3p2su+=Ogf7BSkyq5J4GmmRYw@mail.gmail.com","subject":"Re: Feature idea: Git hook for pre-checkout","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-01-30T02:18:06Z","receivedAt":"2025-01-30T02:18:15Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-01-29 at 10:49:15, Mike Weltevrede wrote:\n> Good morning,\n> \n> I had an idea for a feature in Git. I am not sure if this is the\n> correct channel, but I could not find anything else. If not, could you\n> please let me know the best way to submit this?\n\nThis is the appropriate place to make feature requests.\n\n> Below, I will explain the idea and then the problem that this would solve.\n> \n> <The idea>\n> I have a project that is using Git hooks. Besides pre-commit and\n> pre-push, I would like to use pre-checkout (rather than the already\n> available post-checkout). However, it seems like an active choice not\n> to have pre-checkout given the existing hooks, so I am curious as to\n> the reason behind this.\n> \n> <The problem>\n> I want to do branch name validation when someone does git checkout -b.\n> If the branch name does not meet the requirements, the user should not\n> be allowed to checkout to it. As such, the post-checkout hook does not\n> fully meet my needs. It helps with doing the branch name validation,\n> but if it fails, the user is still on the feature branch. As such, if\n> they are ignorant about the error message, this does not stop them. I\n> am currently combining post-checkout and pre-push but would prefer\n> pre-checkout because this would prevent the user from doing work on\n> this feature branch and having to move their work.\n\nI don't think this is likely to be adopted.  We intentionally don't\nplace a lot of restrictions on local actions, since we assume that a\nsingle user owns the repository and works on it, and they may make a\nwide variety of local changes that are not pushed elsewhere.\n\nIn addition, this change wouldn't really be very effective, since there\nare many ways to bypass it (such as `git branch -m` or `git\nupdate-ref`).  All of those ways also make it very easy to rename a\nbranch as well, which one might well do for non-policy reasons (for\ninstance, if one made a typo) and thus these approaches are assumed to\nbe familiar to the reasonably capable user.  It's also possible to use\none name locally and push to another, such as with\n`git push origin my-feature:refs/features/foo`.\n\nIt also sounds like you're trying to implement a policy decision on the\nlocal system, which is the wrong place, as the Git FAQ outlines[0]:\n\n  How do I use hooks to prevent users from making certain changes?\n\n    The only safe place to make these changes is on the remote repository\n    (i.e., the Git server), usually in the `pre-receive` hook or in a\n    continuous integration (CI) system.  These are the locations in which\n    policy can be enforced effectively.\n\n    It's common to try to use `pre-commit` hooks (or, for commit messages,\n    `commit-msg` hooks) to check these things, which is great if you're\n    working as a solo developer and want the tooling to help you.\n    However, using hooks on a developer machine is not effective as a\n    policy control because a user can bypass these hooks with\n    `--no-verify` without being noticed (among various other ways). Git\n    assumes that the user is in control of their local repositories and\n    doesn't try to prevent this or tattle on the user.\n\n    In addition, some advanced users find `pre-commit` hooks to be an\n    impediment to workflows that use temporary commits to stage work in\n    progress or that create fixup commits, so it's better to push these\n    kinds of checks to the server anyway.\n\nWhile the FAQ mentions `pre-commit` hooks, all of this applies to other\nhooks as well.  The difference between the `pre-commit` hook and your\nproposed `pre-checkout` hook is that the former is generally useful for\nusers outside of a restricted policy environment (e.g., for local\ndevelopment only), whereas the `pre-checkout` hook doesn't appear to be.\n\nOf course, others may have different views, and it's possible that\nJunio might accept a patch to add such a hook if someone sent one.  I'm\nhappy to defer to his judgement in this case.\n\n[0] https://git-scm.com/docs/gitfaq#restrict-with-hooks\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"511489","messageId":"20250130141154.gglc65fegstuzbjy@carbon","threadId":"62868","inReplyTo":"Z5rhXrkbhINwFDXT@tapette.crustytoothpaste.net","subject":"Re: Feature idea: Git hook for pre-checkout","fromName":"Konstantin Khomoutov","fromEmail":"kostix@bswap.ru","sentAt":"2025-01-30T14:11:54Z","receivedAt":"2025-01-30T14:12:20Z","isPatch":false,"sender":{"key":"kostix@bswap.ru","avatar":null},"body":"On Thu, Jan 30, 2025 at 02:18:06AM +0000, brian m. carlson wrote:\n\n[...]\n> It's also possible to use one name locally and push to another, such as with\n> `git push origin my-feature:refs/features/foo`.\n\nI would add that I, for one, have a habit of working on a detached HEAD and\nthen pushing the results with\n\n  git push HEAD:refs/heads/whatever\n\nand only creating a local branch when I think I'm going to abandon the current\nwork for too long (otherwise I just inspect the output of `git reflog HEAD`\nto find the place where I left off and then check it out back).\n\nI don't think it's a widely adopted approach to work with Git, so mentioning\nit more for the purpose of widening the OP's view of the subject matter.\n\n[...]\n\n"},{"id":"511510","messageId":"xmqqy0ysfc2t.fsf@gitster.g","threadId":"62868","inReplyTo":"Z5rhXrkbhINwFDXT@tapette.crustytoothpaste.net","subject":"Re: Feature idea: Git hook for pre-checkout","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-30T17:25:46Z","receivedAt":"2025-01-30T17:25:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> On 2025-01-29 at 10:49:15, Mike Weltevrede wrote:\n>> Good morning,\n>> \n>> I had an idea for a feature in Git. I am not sure if this is the\n>> correct channel, but I could not find anything else. If not, could you\n>> please let me know the best way to submit this?\n>\n> This is the appropriate place to make feature requests.\n\nYes, indeed.\n\n> I don't think this is likely to be adopted.  We intentionally don't\n> place a lot of restrictions on local actions, ...\n> In addition, this change wouldn't really be very effective, ...\n> `git push origin my-feature:refs/features/foo`.\n> It also sounds like you're trying to implement a policy decision on the\n> local system, which is the wrong place, as the Git FAQ outlines[0]:\n\nThanks for raising all good points.\n\nEven though I am negative on adding a hook that does not satisify\nany of the \"5 valid reasons\" [*], this one squarely satisifies (1).\nBut I fully agree with you that it is ineffective as a policy\nenforcement mechanism, and a local hook should not be used as such.\n\nHaving said that, giving reminders locally and early to help users\navoid making mistakes that will be pointed out at the remote at\nreception time via their pre-receive hook, only when the user does\n\"git push\", can still be a good friction reducer.\n\nSo I am not opposed to an idea to have a mechanism that reminds the\nusers of project-specific naming convention of branches and files\n(think: cross platform projects that have participants from case\ninsensitive filesystems) when they create such a thing anew locally,\nespecially the project would have a rejection mechanism when their\nparticipants try to push their changes that adds such a thing.\n\nHere, however, again I agree with you that a pre-checkout hook will\nnot be an effective mechanism to give that reminder.  The mechanism\nmust sit at the ref API layer in order to vet all ways of creating\n(or renaming) a ref in order for to be effectively restrict branch\nnames.  For pathnames, the mechanism must sit at the cache API layer\nto tell add_to_index() what names are problematic.\n\nThanks.\n\n\n[Reference]\n\n*1* There may be slightly updated versions of this in the archive, but\nhttps://lore.kernel.org/git/7vbq7ibxhh.fsf@gitster.siamese.dyndns.org/\nis one of them.\n"},{"id":"511631","messageId":"CAAE-bwV4z8WO2v7FF+kAfNVU8Cd3RsRJV5rLitwZrr=s+PocXw@mail.gmail.com","threadId":"62868","inReplyTo":"xmqqy0ysfc2t.fsf@gitster.g","subject":"Re: Feature idea: Git hook for pre-checkout","fromName":"Mike Weltevrede","fromEmail":"mikeweltevrede@gmail.com","sentAt":"2025-02-01T10:09:22Z","receivedAt":"2025-02-01T10:09:36Z","isPatch":false,"sender":{"key":"mikeweltevrede@gmail.com","avatar":null},"body":"Hi all,\n\nThanks for your swift and elaborate response. I think that those are a\nvery clear explanation and it makes sense to me to take a look into\nthe alternatives you propose.\n\n\nKind regards,\n\nMike Weltevrede\n\nOn Thu, 30 Jan 2025 at 18:25, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> \"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n>\n> > On 2025-01-29 at 10:49:15, Mike Weltevrede wrote:\n> >> Good morning,\n> >>\n> >> I had an idea for a feature in Git. I am not sure if this is the\n> >> correct channel, but I could not find anything else. If not, could you\n> >> please let me know the best way to submit this?\n> >\n> > This is the appropriate place to make feature requests.\n>\n> Yes, indeed.\n>\n> > I don't think this is likely to be adopted.  We intentionally don't\n> > place a lot of restrictions on local actions, ...\n> > In addition, this change wouldn't really be very effective, ...\n> > `git push origin my-feature:refs/features/foo`.\n> > It also sounds like you're trying to implement a policy decision on the\n> > local system, which is the wrong place, as the Git FAQ outlines[0]:\n>\n> Thanks for raising all good points.\n>\n> Even though I am negative on adding a hook that does not satisify\n> any of the \"5 valid reasons\" [*], this one squarely satisifies (1).\n> But I fully agree with you that it is ineffective as a policy\n> enforcement mechanism, and a local hook should not be used as such.\n>\n> Having said that, giving reminders locally and early to help users\n> avoid making mistakes that will be pointed out at the remote at\n> reception time via their pre-receive hook, only when the user does\n> \"git push\", can still be a good friction reducer.\n>\n> So I am not opposed to an idea to have a mechanism that reminds the\n> users of project-specific naming convention of branches and files\n> (think: cross platform projects that have participants from case\n> insensitive filesystems) when they create such a thing anew locally,\n> especially the project would have a rejection mechanism when their\n> participants try to push their changes that adds such a thing.\n>\n> Here, however, again I agree with you that a pre-checkout hook will\n> not be an effective mechanism to give that reminder.  The mechanism\n> must sit at the ref API layer in order to vet all ways of creating\n> (or renaming) a ref in order for to be effectively restrict branch\n> names.  For pathnames, the mechanism must sit at the cache API layer\n> to tell add_to_index() what names are problematic.\n>\n> Thanks.\n>\n>\n> [Reference]\n>\n> *1* There may be slightly updated versions of this in the archive, but\n> https://lore.kernel.org/git/7vbq7ibxhh.fsf@gitster.siamese.dyndns.org/\n> is one of them.\n"}]}