On Thu, Apr 25 2019, Ævar Arnfjörð Bjarmason wrote: > On Thu, Apr 25 2019, Duy Nguyen wrote: > >> On Thu, Apr 25, 2019 at 5:08 PM Ævar Arnfjörð Bjarmason >> <avarab@xxxxxxxxx> wrote: >>> >> Solving (1) without (2) feels like a bit of a missed opportunity to >>> >> me. Ideally, what I would like is >>> >> >>> >> i. A central registry of trustworthy Git hooks that can be upgraded >>> >> using the system package manager to address (2). Perhaps just >>> >> git-hook-* commands on the $PATH. >>> >> >>> >> ii. Instead of putting hooks in .git/hooks, put a list of hooks to >>> >> run for each event in .git/config. >>> > >>> > The problem I had with this when discussing it was that our >>> > configuration system lacks a good way to control inheritance from outer >>> > files. I recently was working with a system-wide gitconfig file that >>> > referred to files I didn't have, and my Git installation was subtly >>> > broken in a variety of ways. >>> > >>> > If I have a system-wide hook to run for company code, but I have a >>> > checkout for my personal dotfiles on my machine where I don't want to >>> > run that hook, our configuration lacks a way for me to disable that >>> > system-wide configuration. However, using our current system, I can >>> > override core.hooksPath in this case and everything works fine. >>> > >>> > I mentioned this for completeness, and because I hope that some of those >>> > people will get some time to chime in here, but I think without that >>> > feature, we end up with a worse experience than we have now. >>> >>> I sent a proposal for this last year "How to undo previously set >>> configuration?": >>> https://public-inbox.org/git/874lkq11ug.fsf@xxxxxxxxxxxxxxxxxxx/ >> >> While reading that mail, it occurs to me that perhaps we can reuse the >> .gitignore idea. >> >> Instead of having a list of untracked files, we have a list of config >> keys. Instead of having .gitignore files associated to different >> directories to apply the rules to those dirs only, we have ignore >> rules that should apply on certain config files (probably based on >> path). >> >> A few differences from your reject/accept/priority example: >> >> - we don't redefine priority, inheritance rules apply the same way >> - reject/accept is handled the same way as positive/negative ignore >> rules. If we're lucky, we could even reuse the exclude code. >> - instead of special section names like >> >> [config "section"] >> >> we have something more like >> >> [config "/this/path"] # (or pattern) >> >> this lets us handle even other config files included by [include] or [includeIf] >> >> So, some examples >> >> [exclude] # exclude from all inherited files >> key = core.* # exclude core.* >> key = !core.bar # but keep core.bar >> >> [excludeIf "path:/etc/config"] # rules apply for only this file >> key = ... >> >> [excludeIf "glob:/home/*"] # rules apply for these config paths >> key = ... >> >> [excludeIf "system"] # special names for convenience maybe >> key = ... >> >>> Obviously the main bottleneck is someone like me working on patching it, >> >> Yes, manpower is always the problem. >> >>> but in this case it would be very useful if those who are interested in >>> this could look that proposal over and bikeshed it / point out issues I >>> may have missed, i.e. "no, this categorically won't work with this >>> proposed syntax due to XYZ you haven't thought of...". > > Thanks, I like this syntax/proposal much better than my initial one, > especially re-using the syntax we have in .gitignore. Also in that it's > more similar to the existing include syntax, which in retrospect with an > example is the obviously better choice both in terms of UI consistency > and flexibility. > > I.e. I didn't want config files by globs, because depending on compile > options the /etc/gitconfig may be in /opt/etc/gitconfig, but as your > '[excludeIf "system"]' and '[excludeIf "path:/etc/config"]' examples > show we can have our cake and eat it too, and as you demonstrate there's > other reasons to do path globs that excluding the "git config > --{system,global,local,worktree}" file doesn't cover. > > Re priorities: My "I don't really have a use-case for that" in 2018 is > still 95% true, just a couple of things: > > 1. Having it would be a really nice smoke test for this working > properly, i.e. now all the config parsing is "streamed" to its > consumers via callbacks, having priorities would require the ability > to pre-buffer and re-arrange it, the "pre-buffer" you'd need for any > exclude mechanism anyway. > > Once we have that "priorities" should just be a quick sort of what > order we loop over the files in. > > 2. There is the use-case of "I don't want to exclude core.* from config > file <A>, I just want file <B> to override it". I can imagine > especially if/when we have in-repo .gitconfig that you'd want to > trust say core.* from there, but have you ~/.gitconfig override it > if you've bothered to set any of them yourself. > > But I think most of that use-case doesn't need priorities. It could > just be another "exclude" syntax for common cases, e.g.: > > # ...Having done something else previously to opt-in to scary > # in-repo .gitconfig... > [excludeIf "repo"] > key = core.* # exclude core.* > [excludeIf "repo"] > existingKey = true # exclude any existing key > > So e.g. you'd keep that .gitconfig's gc.bigPackThreshold or > whatever, unless your ~/.gitconfig (parsed before, lower priority) > had already set it. A #3 I just encountered[1] where this settable "config priority" might be handy, but perhaps it's still stupid and exclusions are enough: * Vendor's git server wants to run 'git -c gc.writeCommitGraph gc' to get commit graphs. I might want to override it. * The vendor can't just add that to /etc/gitconfig because they don't want to screw with the OS, or might not know which "git" they'll use (their own or OS, so system "gitconfig" in different places/inconsistent) So something where they can just do that and I can in what *I* know to be the system "gitconfig" do: [configPriority "cli-at-cwd:/var/lib/vendor/git-storage/*"] value = 5 If I know they'll be be running those commands on that path, and I'd like to s/100/5/ the priority for "-c" there so it goes last (see the suggested priority numbers in [2]). Or maybe alternatively, we'd have something like "-c" (unfortunately "-C" is taken) to add a new config file to the mix, without making it an all-or-nothing like GIT_CONFIG_NOSYSTEM=1 and GIT_CONFIG=<path>). So they: git --add-this-config-last-please=/var/lib/vendor/etc/gitaly/gitconfig gc And then I do in /etc/gitconfig: [excludeIf "glob:/var/lib/vendor/etc/gitaly/gitconfig"] key = gc.* But priorities might still be sensible. This use-case could be alternatively done without them with a more sensible version of "excludeIf.existingKey" discussed in the last mail. I.e. having "existingKey" be a glob, not "true": [excludeIf "glob:/var/lib/vendor/etc/gitaly/gitconfig"] existingKey = gc.* Ditto for "-c" values: [excludeIf "cli-at-cwd:/var/lib/vendor/git-storage/*"] existingKey = gc.* So maybe I've managed to talk myself out this whole notion of priorities. I.e. maybe we can always process config in a pre-determined order and just allow people to reach forward/backward with [excludeIf path/glob/-c at cwd] & [exclude], respectively. There's still the *theoretical* use-case of a user saying "I know the sysadmin here knows better, I want their /etc/gitconfig to go after my ~/.gitconfig", but does anyone need/want it in practice? I don't know... 1. https://gitlab.com/gitlab-org/gitaly/issues/1643 2. https://public-inbox.org/git/874lkq11ug.fsf@xxxxxxxxxxxxxxxxxxx/
