>>>>> On 2008-08-22 14:10 PDT, Junio C Hamano writes:
Junio> Karl Chen <quarl@xxxxxxxxxxxxxxx> writes:
>> Another idea is to have a non-absolute path be interpreted
>> relative to the location of .gitconfig.
Junio> If we were to support relative paths, I think it would
Junio> be useful and consistent if a relative path found in
Junio> ".git/config" is relative to the work tree root, in
Junio> "config" in a bare repository relative to the bare
Junio> repository, and in "$HOME/.gitconfig" relative to
Junio> $HOME.
Makes sense to support it everywhere. For .git/config, isn't it
more consistent for it to be relative to .git?
Junio> I am not sure what a relative path in "/etc/gitconfig"
Junio> should be relative to, though.
Why not just relative to the location of that file? Normally
/etc, but if some distro customizes the location of /etc/gitconfig
(/etc/git/config), or on non-Linux/posix systems it's somewhere
else, or git is installed in /usr/local or /opt or $HOME, then
it's still relative to the location of system gitconfig.
Junio> However, this has a technical difficulty. When
Junio> configuration values are read, the code that knows what
Junio> the value means does not in general know which
Junio> configuration file is being read from.
Sounds like a refactoring issue.
Junio> It is quite likely that somebody would want you to
Junio> interpret "~name/" if you advertize that you support
Junio> "~/", so you would need to call getpwuid() eventually
Junio> if you go down this path. I wonder how this would
Junio> affect Windows folks.
I would be happy either way. Though since git uses getenv("HOME")
to find ~/.gitconfig, I can see arguments for looking for the
ignore file there also, in case it's different.
Junio> we would need a "--path" option to "git config" (the
Junio> idea is similar to existing "--bool" option) so that
Junio> calling scripts can ask the same "magic" performed to
Junio> configuration variables' values before being reported.
Sounds fine.
So, being new to git development, am I correctly assessing your
response as "with refinement this can be included in git"?
Relative paths and ~ (and $HOME) are all mutually compatible so
they could all be implemented. If $HOME were supported directly
(either just "$HOME" or parsing all $ENVVARS) then it'd be easier
to decide to use getpwuid for ~. Personally I'd use: 1) relative
path, 2) $HOME (as "~" or "$HOME"), 3) getpwuid (as "~")
Karl
--
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
