On Sat, Sep 29, 2018 at 10:27:15PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > And I think this has to be stderr. We're polluting the output of the
> > aliased command with our extra message, so we have two choices:
> >
> > 1. Pollute stderr, and risk copious stdout (or a pager)
Jeff King writes:
> And I think this has to be stderr. We're polluting the output of the
> aliased command with our extra message, so we have two choices:
>
> 1. Pollute stderr, and risk copious stdout (or a pager) scrolling it
> off the screen.
>
> 2. Pollute stdout, at which point our
On Sat, Sep 29, 2018 at 10:39:54AM -0700, Junio C Hamano wrote:
> Suppose "git foo" is aliased to a command "git bar".
>
> The best case is when "git bar -h" knows that it is asked to give us
> a short usage. We get "foo is aliased to bar" followed by the short
> usage for "bar" and everything
Jeff King writes:
> Right, I'm proposing only to add the extra message and then continue as
> usual.
>
> It is a little funny, I guess, if you have a script which doesn't
> respond to "-h", because you'd get our "foo is aliased to git-bar"
> message to stderr, followed by who-knows-what. But as
On Fri, Sep 28, 2018 at 10:18:05AM +0200, Rasmus Villemoes wrote:
> > it, and then it is up to the alias to handle "-h" sensibly.
>
> I'd be nervous about doing this, though, especially if we introduce this
> without a new opt-in config option (which seems to be the direction the
>
Rasmus Villemoes writes:
>>> + if (follow_alias > 0) {
>>> + fprintf_ln(stderr,
>>> + _("Continuing to help for %s in %0.1f
>>> seconds."),
>>> + alias, follow_alias/10.0);
>>> +
On 2018-09-26 20:49, Jeff King wrote:
> On Wed, Sep 26, 2018 at 08:16:36AM -0700, Junio C Hamano wrote:
>
>>
>> If we expect users to use "git cp --help" a lot more often than "git
>> help cp" (or the other way around), one way to give a nicer experience
>> may be to unconditionally make "git cp
On 2018-09-26 20:12, Taylor Blau wrote:
>
> In the case where you are scripting (and want to know what 'git co'
> means for programmatic usage), I think that there are two options. One,
> which you note above, is the 'git -c help.followAlias=false ...'
> approach, which I don't think is so bad
On 2018-09-26 17:19, Duy Nguyen wrote:
> On Wed, Sep 26, 2018 at 4:42 PM Taylor Blau wrote:
>>> +
>>> + /*
>>> + * We use split_cmdline() to get the first word of the
>>> + * alias, to ensure that we use the same rules as when
>>> + * the alias
On 2018-09-26 17:16, Junio C Hamano wrote:
> Rasmus Villemoes writes:
>
>> +/*
>> + * We use split_cmdline() to get the first word of the
>> + * alias, to ensure that we use the same rules as when
>> + * the alias is actually used. split_cmdline()
Jeff King writes:
>> When you have "[alias] cp = cherry-pick -n", "git cp --help" should
>> not do "git help cherry-pick". Only a single word that exactly
>> matches a git command should get this treatment.
>
> I'm not sure I agree. A plausible scenario (under the rules I gave
> above) is:
>
>
On Wed, Sep 26, 2018 at 08:16:36AM -0700, Junio C Hamano wrote:
> > This introduces a help.followAlias config option that transparently
> > redirects to (the first word of) the alias text (provided of course it
> > is not a shell command), similar to the option for autocorrect of
> > misspelled
Taylor Blau writes:
> This pause (though I'm a little surprised by it when reviewing the
> code), I think strikes a good balance between the two, i.e., that you
> can get help for whatever it is aliased to, and see what that alias is.
And I need to react to it within subsecond with ^C when I
On Wed, Sep 26, 2018 at 08:16:36AM -0700, Junio C Hamano wrote:
> Rasmus Villemoes writes:
>
> > I often use 'git --help' as a quick way to get the documentation
> > for a command. However, I've also trained my muscle memory to use my
> > aliases (cp=cherry-pick, co=checkout etc.), which means
On Wed, Sep 26, 2018 at 08:30:32AM -0700, Junio C Hamano wrote:
> Taylor Blau writes:
>
> >> +help.followAlias::
> >> + When requesting help for an alias, git prints a line of the
> >> + form "'' is aliased to ''". If this option is
> >> + set to a positive integer, git proceeds to show the
Taylor Blau writes:
>> +help.followAlias::
>> +When requesting help for an alias, git prints a line of the
>> +form "'' is aliased to ''". If this option is
>> +set to a positive integer, git proceeds to show the help for
>
> With regard to "set to a positive integer", I'm not sure
On Wed, Sep 26, 2018 at 4:42 PM Taylor Blau wrote:
> > +
> > + /*
> > + * We use split_cmdline() to get the first word of the
> > + * alias, to ensure that we use the same rules as when
> > + * the alias is actually used. split_cmdline()
> > +
On Wed, Sep 26, 2018 at 12:29 PM Rasmus Villemoes
wrote:
>
> I often use 'git --help' as a quick way to get the documentation
> for a command. However, I've also trained my muscle memory to use my
> aliases (cp=cherry-pick, co=checkout etc.), which means that I often end
> up doing
>
> git cp
Rasmus Villemoes writes:
> I often use 'git --help' as a quick way to get the documentation
> for a command. However, I've also trained my muscle memory to use my
> aliases (cp=cherry-pick, co=checkout etc.), which means that I often end
> up doing
>
> git cp --help
>
> to which git correctly
On Wed, Sep 26, 2018 at 12:26:36PM +0200, Rasmus Villemoes wrote:
> I often use 'git --help' as a quick way to get the documentation
> for a command. However, I've also trained my muscle memory to use my
> aliases (cp=cherry-pick, co=checkout etc.), which means that I often end
> up doing
>
>
I often use 'git --help' as a quick way to get the documentation
for a command. However, I've also trained my muscle memory to use my
aliases (cp=cherry-pick, co=checkout etc.), which means that I often end
up doing
git cp --help
to which git correctly informs me that cp is an alias for
21 matches
Mail list logo
