Re: [PATCH] introduce git root

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 2, 2014 at 8:04 AM, Jeff King <peff@xxxxxxxx> wrote:
> 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@xxxxxxxxx> 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.

> 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.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]