On Tue, Apr 14, 2020 at 08:45:50PM -0700, Jonathan Nieder wrote: > > Yeah, I do see how that use case makes sense. I wonder how common it is > > versus having separate one-off hooks. > > I think separately from the frequency question, we should look at the > "what model do we want to present to the user" question. I sort of agree. The mental model is important, but we should avoid presenting a model that is overly complex to a user who only wants to do simple things. So how common that simple thing is impacts the answer to your question. > [...] > What I mean to get at is that I think thinking of them in terms of > individual hooks, the user model assumed by these programs is to think > of them as plugins hooking into Git. The individual hooks are events > that the plugin listens on. If I am trying to disable a plugin, I > don't want to have to learn which events it cared about. Sure, I agree that's a perfectly reasonable mental model. But for somebody who just wants to do a one-off hook, they're now saddled with a thing they don't care about: defining a plugin group for their hook. The examples you gave are all reasonable, but personally I've never used anything other than one-off hooks. On the other hand, I've very rarely used hooks at all myself. To be clear, I don't _really_ care all that much, and this isn't a hill I particularly care to die on. I was mostly just clarifying my earlier suggestion. (I _am_ somewhat amazed that the simple concept of "I would like to run this shell command instead of $GIT_DIR/hooks/foo" has generated so much discussion. So really I am in favor of whatever lets me stop thinking about this as soon as possible). > > And whether setting the order > > priority for all hooks at once is that useful (e.g., I can easily > > imagine a case where the pre-commit hook for program A must go before B, > > but it's the other way around for another hook). > > This I agree about. Actually I'm skeptical about ordering > dependencies being something that is meaningful for users to work with > in general, except in the case of closely cooperating hook authors. > > That doesn't mean we shouldn't try to futureproof for that, but I > don't think we need to overfit on it. I share that skepticism (and also agree that avoiding painting ourselves into a corner is the main thing). > >>> And it doesn't leave a lot of room for defining > >>> per-hook-type options; you have to make new keys like pre-push-order > >>> (though that does work because the hook names are a finite set that > >>> conforms to our config key names). > > Exactly: field names like prePushOrder should work okay, even if > they're a bit noisy. A side note: Here you've done a custom munging of pre-push into prePush. I'm fine with that, but would we ever want to allow third-party scripts to define their own hooks using this mechanism? E.g., if there's a git-hooks command could I run "git hooks run foo" to run the foo hook? If so, then it might be simpler to just use the name as-is rather than defining the exact munging rules. -Peff
