On Thu, Feb 09, 2012 at 08:24:42PM +0100, Jakub Narebski wrote: > > So the patch would look something like this. However, is the actual > > filename really what callers want? It seems like in David's case, an > > annotation of "repo", "global", or "system" (possibly in addition to the > > filename) would be the most useful (because in the git-cola UI, it is > > still nice to list things as "repo" or "global" instead of spewing the > > whole filename at the user -- but you would still want the individual > > filename for handling updates of includes). > > I'm not sure if "system" / "global" / "local" or "repo" would be a good > idea. > > First, in the case of includes you would have to provide pathnames of > included files. This would introduce inconsistency. Is "system" > the '/etc/gitconfig' file, or 'system' file in '.git' directory? Yeah, it would have to be syntactically unambiguous with the filename. I was thinking something of just including both, like this: global:/home/peff/.gitconfig<TAB>include.path=other-file global:/home/peff/other-file<TAB>some.key=value That is, give a "context" (repo, global, system) to each lookup, and then mention the individual file as well (either because it is the root of that context, or because it was included). So a config editor could present the context to the user as a purely decorative thing (i.e., tell the user "these options affect all of your repos"), but use the filename to actually update the values (i.e., "git config -f /home/peff/other-file some.key newvalue"). > Second, people can have different build configuration, e.g. the prefix > might differ, so that "system" is not always '/etc/gitconfig'. If you > want to edit config you would want to know which file to edit... and though > there is "git config --system --edit" it depends on having editor > configured correctly. Without includes, something like git-cola could possibly get away with: git config --system some.key value but that doesn't work for included files; for those, you'd want to have the actual filename. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html