Hi Liliana, Liliana Marie Prikler <liliana.prik...@gmail.com> writes:
> Hi Guix, > > as we all are more or less aware of, Guix automates quite much of the > user's configuration for comfortably hacking on our codebase. As has > been argued elsewhere, both by myself and fellow Guix, this is not > always a good thing. > > Let's start with the cleanest example of how to do things the right > way: Our Emacs configuration is split across two files (one of which is > a directory, but let's get back to that). One of them are the > directory-local variables stored in .dir-locals.el, the other the > snippets in etc/snippets–if you're using YASnippet, the former loads > the latter. I have no qualms with this being automated, as Emacs > itself gives me plenty opportunity of opting out of it. I could > declare any of the included variables or forms unsafe and ignore them > in future sessions. Likewise, I can mark them as safe to affirm my > consent that these variables be changed in /path/to/guix/checkout. > > None of this holds for the git config, which we install unasked in the > working tree with a DATA target that we want neither distributed nor > installed otherwise. This has led to confusion both in the mailing > lists and the IRC on multiple occasions, so I'd propose we instead use > PHONY targets for: > 1. git-hooks to install the git hooks that committers need. > 2. git-config to install all of the git config > a. git-config-diff to just install the diff xfuncs > b. git-config-format to just install the format block > c. git-config-pull to just install the pull block > d. git-config-sendemail to just install the sendemail block > 3. git-fullconfig for both 1 and 2. As argued before, going this route would have the following downsides: 1. the pre-push-hook would no longer be installed out of the box, which could mean forgotting to sign a commit and having to ask Savannah folks to drop the offending commit(s). That's a blocker for me, at least until we have a server-side hook that can guard against this. 2. The pre-push-hook could go stale (not self-updating). That's likely to happen as people would seldom run 'make git-hooks' to refresh them. 3. We'd loose some notifications for teams, likely for first submissions from users that have yet to run 'make git-hooks', or from users who chose not too. 4. We'd have more problems applying patches since the 'useAutoBase = true' is not enabled by default, and documentation is a weak assurance that users will do this. > Internally, these would still be based on the actual file names to get > time-stamps to work. Thus, on a fresh pull or if you haven't pulled in > a while, you can run either `git fullconfig` or any of the above to set > things up. > > Incidentally, my .git/config currently reads the following: > > [include] > path = ../etc/git/gitconfig > path = ../etc/git/gitconfig > path = ../etc/git/gitconfig > path = ../etc/git/gitconfig That should be fixed in Git. 'git config --add include.path ../etc/git/gitconfig' should not be re-adding the same entries over and over if they are already there. All in all, I guess my position is unchanged: despite the potential for surprises, automating and enforcing these configs provide benefits that outweigh the cons, in my experience/opinion. -- Thanks, Maxim