Re: [PATCH 0/2] config includes, take 2
- From
David Aguilar <davvid@gmail.com>
- Date
- Feb 7, 2012, 20:15 UTC
- Message-ID
- <CAJDDKr5uTj0Jav=3Kwf4Atd81qn1x9CLTveZOPmWwsnNCT9Lhw@mail.gmail.com>
- In-Reply-To
- <m31uq63143.fsf@localhost.localdomain>
On Tue, Feb 7, 2012 at 11:16 AM, Jakub Narebski <jnareb@gmail.com> wrote:
Show 18 quoted lines
> Jeff King <peff@peff.net> writes: > > [...] >> Git-config could potentially help with that (and even simplify the >> current code) by allowing something like: >> >> $ git config --list-with-sources >> /home/peff/.gitconfig user.name=Jeff King >> /home/peff/.gitconfig user.email=peff@peff.net >> .git/config core.repositoryformatversion=0 >> .git/config core.bare=false >> [etc] >> >> (you would use the "-z" form, of course, and the filenames would be >> NUL-separated, but I made up a human-readable output format above for >> illustration purposes). > > That would be _very_ nice to have (even without includes support).
I like this as well.
Thanks for digging deep into this one, Jeff. You've convinced me that not following includes is the better default behavior.
You are correct in mentioning that what was really missing was something akin to "git config --repo --list". Since that command would be a shortcut for "-f .git/config" then it would be consistent in behavior. The suggestion to have the app understand .[include] path = and show separate panes for included files is an elegant solution and definitely helpful for power users. I do have to write more code but that's fine since it enables new functionality.
Jeff, you mentioned possibly adding a "backwards-compatible way" of accessing this stuff and hiding it behind an environment variable. I don't want to make us carry around backwards compat code paths just for one particular use case so perhaps the best thing would be for me to start preparing for this change now. I already have various places where functionality is guarded behind a git version check. If what we're talking about is git-cola adding "--include" when git >= 1.8(?) then that works for me.
It should be noted that git-gui also uses `git config --global --list` so I don't know if this has implications there. E.g. maybe things like user.name won't be overridden if done via an included config there.
RE: the caching -- we call git config a few times in various places. Getting the user.* fields. Getting the diff.summary settings, etc. I started tweaking app startup for speed and noticed all the git-config calls and was able to replace a handful of calls with a single call, which was nice. The difference is more pronounced on win32 (I am a linux user but I do try to play nice with the msysgit folks).
Thanks Jeff,
-- David