Re: [PATCH] Support "core.excludesfile = ~/.gitignore"

    Junio> Karl Chen <quarl@cs.berkeley.edu> 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