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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 24, 2008, 18:11 UTC
Message-ID: <7vprnyqo59.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <quack.20080824T0140.lth3aku956e@roar.cs.berkeley.edu>

Karl Chen <quarl@cs.berkeley.edu> writes:

Show 11 quoted lines

>>>>>> On 2008-08-22 14:10 PDT, Junio C Hamano writes:
>
>     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?

Consistency and usefulness are different things. Suppose you want as the upstream of your project maintain and distribute a mail-alias list in-tree (say, the file is at the root level, CONTRIBUTORS), and you suggest contributors to use it when using "commit --author".

Which one do you want to write in your README:

	[user]
        	nicknamelistfile = ../CONTRIBUTORS

or

	[user]
        	nicknamelistfile = CONTRIBUTORS

You have to say the former if it is relative to .git/config.

> So, being new to git development, am I correctly assessing your
> response as "with refinement this can be included in git"?

I do not have fundamental objection to what you are trying to achieve (i.e. being able to say "relative to $HOME"). I personally think the approach you took in your patch (i.e. only support "~/" and use $HOME, without any other fancy stuff) is a sensible first cut for that issue.

I just pointed out possible design issues about the future direction after that first cut. When I make comments on design-level issues, I rarely read the patch itself very carefully, so it is a different issue if your particular implementation in the patch is the best implementation of that first cut approach.