Re: [PATCH] introduce git root

From: Christian Couder <christian.couder@gmail.com>
Date: Dec 2, 2014, 10:05 UTC
Message-ID: <CAP8UFD2P+GZ7Da+YcmjtYiYsESt+BdWc006NN6ps_X_n-We4iA@mail.gmail.com>
In-Reply-To: <20141202070415.GC1948@peff.net>

On Tue, Dec 2, 2014 at 8:04 AM, Jeff King <peff@peff.net> wrote:

Show 25 quoted lines

> On Mon, Dec 01, 2014 at 05:17:22AM +0100, Christian Couder wrote:
>
>> On Mon, Dec 1, 2014 at 4:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> >
>> > If I were redoing this today, I would probably nominate the "git"
>> > potty as such a "kitchen synk" command.  We have "--man-path" that
>> > shows the location of the manual pages, "--exec-path[=path]" that
>> > either shows or allows us to override the path to the subcommands,
>> > and "--show-prefix", "--show-toplevel", and friends may feel quite
>> > at home there.
>>
>> I wonder if we could reuse "git config" which is already a "kitchen
>> synk" command to get/set a lot of parameters.
>> Maybe we could dedicate a "git" or "virtual" or "proc" or "sys" (like
>> /proc or /sys  in Linux) namespace for these special config parameters
>> that would not necessarily reflect something in the config file.
>>
>> "git config git.man-path" would be the same as "git --man-path".
>> "git config git.root" would be the same as "git rev-parse --show-toplevel".
>> "git config git.exec-path mypath" would allow us to override the path
>> to the subcommands, probably by saving something in the config file.
>
> What would:
>
>   git config git.root foo

That would output an error message saying that we cannot change the git.root value.

>   git config git.root

That would output the same as "git rev-parse --show-toplevel".

> output? No matter what the answer is, I do not relish the thought of
> trying to explain it in the documentation. :)

Yeah, maybe it is better if we don't reuse "git config".

> There is also "git var", which is a catch-all for printing some deduced
> environmental defaults. I'd be just as happy to see it go away, though.

Yeah, maybe we could use "git var" for more variables.

Show 11 quoted lines

> Having:
>
>   git --exec-path
>   git --toplevel
>   git --author-ident
>
> all work would make sense to me (I often get confused between "git
> --foo" and "git rev-parse --foo" when trying to get the exec-path and
> git-dir). And I don't think it's too late to move in this direction.
> We'd have to keep the old interfaces around, of course, but it would
> immediately improve discoverability and consistency.

I don't like reusing the git command for that puropose, because it clutters it and makes it difficult to improve.

For example let's suppose that we decide to have a "git info" command. It could work like this:

$ git info sequence.editor vim

$ git info core.editor emacs

$ git info --verbose sequence.editor sequence.editor = vim GIT_EDITOR = emacs core.editor = nano

$ git info --verbose core.editor GIT_EDITOR = emacs core.editor = nano

So the --verbose option could explain why the sequence.editor is vim by displaying the all the relevant options with their values from the most important to the least important.

Best, Christian.