Re: [PATCH 4/4] config: allow including config from repository blobs

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 27, 2012, 23:10 UTC
Message-ID: <7v39b0zqqh.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4F2251D4.9060005@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 19 quoted lines

> Am 1/27/2012 6:42, schrieb Jeff King:
>> That being said, I think it would be nicer for projects to carry meta
>> information like this out-of-tree in a special ref. It's just simpler to
>> work with, and it means the project's source isn't polluted with extra
>> junk.
>
> Really? I doubt that carrying configuration in a special ref outside the
> normal contents will have any practical relevance:
>
> To manage such a config file would mean to switch to a branch with
> entirely different contents. But before you can test the new configuration
> in action, you have to commit, switch branches, which exchanges the
> worktree completely; and if the config change didn't work out, repeat the
> process (and if we are talking about source code repository, this usally
> includes a complete rebuild). Sure, you could keep the config branch in a
> separate repository, but, again, how do you test an updated configuration?
> It is not funny, and nobody will go this route.
>
> Which raises doubts about the usefulness of the include.ref feature.

Hmm, good point.

What I envisioned, when I said "meta:gitconfig" might make sense, was to do something like:

 * have a separate worktree via git-new-worktree in meta/, so that you
   do not have to switch away from the "source" branch and trash the
   working tree for it; and

 * update meta/gitconfig, perhaps make commit there, and possibly push
   it back for public consuption.

In other words, I think "you *could* keep the config branch in a separate repository" is more like "you would most likely want to have a separate checkout of the config branch for this 'meta' branch to be useful".

And at that point, as you said, setting include.path = meta/gitconfig (with possibly adding meta/ in .git/info/exclude) would be far more pleasant, because you would have a chance to experiment your changes to the file before committing it.

So having include.ref, while it is a fun thought experiment, would not help very much in the real life.