Jeff King writes:
> On Tue, Dec 09, 2014 at 10:17:13AM -0800, Junio C Hamano wrote:
>
>> This is another tangent that comes back to the original "how to name
>> them?" question, but I wonder if a convention like this would work.
>>
>> * When asking for a feature (e.g. "what editor to use"), if
On Tue, Dec 09, 2014 at 10:17:13AM -0800, Junio C Hamano wrote:
> It is a tangent, the current definition of "git_editor" helper reads
> like this:
>
> git_editor() {
> if test -z "${GIT_EDITOR:+set}"
> then
> GIT_EDITOR="$(git var G
On Tue, Dec 9, 2014 at 7:17 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> But the one place I do not agree is:
>>
>>> I think "sequence.editor" and "core.editor" are better because:
>>>
>>> - they use the same syntax as the config variables, so they are easier
>>> to remember and to discover
Jeff King writes:
> But the one place I do not agree is:
>
>> I think "sequence.editor" and "core.editor" are better because:
>>
>> - they use the same syntax as the config variables, so they are easier
>> to remember and to discover, and
>
> I really don't like using "core.editor" here, because
On Fri, Dec 5, 2014 at 10:27 AM, Jeff King wrote:
> On Fri, Dec 05, 2014 at 03:27:17AM +0100, Christian Couder wrote:
>
>> > I do not think "git var --exec-path" is a good idea, nor GIT_EXEC_PATH
>> > for the environment-variable confusion you mentioned. I was thinking of
>> > just creating a new
On Fri, Dec 05, 2014 at 03:27:17AM +0100, Christian Couder wrote:
> For example, to chose the editor all the following could apply:
>
> GIT_SEQUENCE_EDITOR env variable
> sequence.editor config variable
> GIT_EDITOR env variable
> core.editor config variable
> VISUAL env variable
> EDITOR env var
Jeff King wrote:
> Some of the discussion has involved mixing config options into this
> kitchen sink, but that does not make any sense to me (and is why I
> find "git var -l" so odd). Config options are fundamentally different, in
> that they are set and retrieved, not computed (from other confi
Jeff King writes:
> ... I was thinking of
> just creating a new namespace, like:
>
> git var exec-path
> git var author-ident
>
> and deprecating the 4 existing GIT_* variables.
I'm fine with that. As I wrote in my response to MMoy, I forgot
about other kinds of options the "git" potty take
On Thu, Dec 04, 2014 at 11:02:37AM -0800, Junio C Hamano wrote:
> > Christian raised the issue of cluttering the "git --option" namespace,
> > and I do agree that's a potential issue.
>
> I am not sure if that is an issue at all. You will need the same
> number of options to cover all the neces
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Jeff King writes:
>>
>>> Christian raised the issue of cluttering the "git --option"
>>> namespace,
>>> and I do agree that's a potential issue.
>>
>> I am not sure if that is an issue at all. You will need the same
>> number of options to cov
Junio C Hamano writes:
> Jeff King writes:
>
>> Christian raised the issue of cluttering the "git --option"
>> namespace,
>> and I do agree that's a potential issue.
>
> I am not sure if that is an issue at all. You will need the same
> number of options to cover all the necessary "computables"
Jeff King writes:
> On Tue, Dec 02, 2014 at 09:26:00AM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > 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.
>> > Having:
>> >
>> > git --
On Tue, Dec 02, 2014 at 09:26:00AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > 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.
> > Having:
> >
> > git --exec-path
> > git --toplevel
Jeff King writes:
> 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.
> Having:
>
> git --exec-path
> git --toplevel
> git --author-ident
>
> all work would make sense to me (I often get confused
On Tue, Dec 2, 2014 at 8:04 AM, Jeff King 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 wrote:
>> >
>> > If I were redoing this today, I would probably nominate the "git"
>> > potty as such a "kitchen synk" command.
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 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
Christian Couder writes:
> I wonder if we could reuse "git config" which is already a "kitchen
> synk" command to get/set a lot of parameters.
I doubt it makes much sense.
* Things like toplevel and cdup are not even something you
configure. It is where you are, the current state of you.
On Mon, Dec 1, 2014 at 4:04 AM, Junio C Hamano 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 overri
Matthieu Moy writes:
> ... git rev-parse --show-toplevel is not just long,
> it's just not the place where people would look for (it's neither about
> revision nor about parsing, so clearly, "rev-parse" is not a good place
> to host the feature in the UI).
For the record, "rev-parse" is not abou
Arjun Sreedharan writes:
> On 30 November 2014 at 04:38, Philip Oakley wrote:
>> From: "Arjun Sreedharan"
>>>
>>> This introduces `git root` which outputs the root directory
>>> (the directory that contains .git).
>>> The same can be accomplished by `git rev-parse --show-toplevel`.
>>> `git roo
On 30 November 2014 at 04:38, Philip Oakley wrote:
> From: "Arjun Sreedharan"
>>
>> This introduces `git root` which outputs the root directory
>> (the directory that contains .git).
>> The same can be accomplished by `git rev-parse --show-toplevel`.
>> `git root` is much more intuitive and easy
From: "Arjun Sreedharan"
This introduces `git root` which outputs the root directory
(the directory that contains .git).
The same can be accomplished by `git rev-parse --show-toplevel`.
`git root` is much more intuitive and easy to remember.
All it does is set the arguments for rev-parse
This
This introduces `git root` which outputs the root directory
(the directory that contains .git).
The same can be accomplished by `git rev-parse --show-toplevel`.
`git root` is much more intuitive and easy to remember.
All it does is set the arguments for rev-parse
Signed-off-by: Arjun Sreedharan
-
23 matches
Mail list logo
