Karl Chen <quarl@xxxxxxxxxxxxxxx> writes:
>>>>>> 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.
--
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
