You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
it would be nice if this repo would be configurable without touching the worktree. i use this repo extensively in my local work environments, where it's kind of annoying to have a "dirty" tree, especially since i like to send my contributions back here. ;)
typically, git hooks would consult the configuration stored in git-config, for example... is that something that would be accepted as a patch? maybe as an override to the config file?
this would also allow different people with different policies to use the same code more easily. the canonical example for me is #9, where we have more ... relaxed documentation policies (because of an old codebase).
in fact, now that i think of it, this would make it possible to have per-repository (say you're not in a monorepo) policies, while using the same hook repository everywhere...
The text was updated successfully, but these errors were encountered:
i'll think about it... there are lots of settings. :p
maybe the design would be that the defaults would be defined in the config file, and then ask for the same setting (lowercased) in git config... but then the devil is in the details...
I think if this feature will be implemented, the config from this repo should be the default and user and project git config should get higher precedence.
And sure the details will be hard to get.
It would be nice if you implement it. I guess here we don't have enough time to do it yet.
it would be nice if this repo would be configurable without touching the worktree. i use this repo extensively in my local work environments, where it's kind of annoying to have a "dirty" tree, especially since i like to send my contributions back here. ;)
typically, git hooks would consult the configuration stored in
git-config
, for example... is that something that would be accepted as a patch? maybe as an override to the config file?this would also allow different people with different policies to use the same code more easily. the canonical example for me is #9, where we have more ... relaxed documentation policies (because of an old codebase).
in fact, now that i think of it, this would make it possible to have per-repository (say you're not in a monorepo) policies, while using the same hook repository everywhere...
The text was updated successfully, but these errors were encountered: