On 2018-09-26 17:16, Junio C Hamano wrote:
> Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx> 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()
>> + * modifies alias in-place.
>> + */
>> + count = split_cmdline(alias, &argv);
>> + if (count < 0)
>> + die("Bad alias.%s string: %s", cmd,
>> + split_cmdline_strerror(count));
>> +
>> + if (follow_alias > 0) {
>> + fprintf_ln(stderr,
>> + _("Continuing to help for %s in %0.1f seconds."),
>> + alias, follow_alias/10.0);
>> + sleep_millisec(follow_alias * 100);
>> + }
>> + return alias;
>
> If you have "[alias] cp = cherry-pick -n", split_cmdline discards
> "-n" and the follow-alias prompt does not even tell you that it did
> so,
That's not really true, as I deliberately did the split_cmdline after
printing the "is an alias for", but before "continuing to help for", so
this would precisely tell you
cp is an alias for 'cherry-pick -n'
continuing to help for 'cherry-pick' in 1.5 seconds
> and you get "git help cherry-pick". This code somehow expects
> you to know to jump to the section that describes the "--no-commit"
> option. I do not think that is a reasonable expectation.
No, in that case I would not expect git cp --help to jump to that
section anymore than I would expect "git cherry-pick -n --help" to
magically do that (and that would be impossible in general, if more
options are bundled in the alias).
> 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 considered that, and could certainly live with that. But it seems the
discussion took a different turn in another part of the thread, so I'll
continue there.
Rasmus
