Excerpts from Ryan McElroy's message of 2017-03-21 20:32:56 +0000: > > On 3/21/17 7:34 PM, Jun Wu wrote: > > Excerpts from Phillip Cohen's message of 2017-03-21 12:21:33 -0700: > >>> Have you actually tried if "commandname" is the command name after > >>> resolving > >>> alias? > >> It is, for command aliases. For example `hg sf` will correctly return > >> `absorb`. > > "sf" is unambiguous because it's hard-coded by absorb.py. > > > > I think Ryan is more interested in ambiguous cases caused by user-defined > > [alias]. > > I'm actually interested in our internal logging. Today, our > command-guessing code in the wrapper is really quite terrible and > doesn't normalize as well as I would like. We should be using > commandname instead, it sounds like, and passing that back to our > logging wrapper. I would sure hate to lose that functionality right > after I just learned it exists already (I was thinking about adding it > otherwise). > > I'm only slightly concerned about users not knowing what their aliases > are. I'm much more interested in debug-ability and consistency in > reporting for stats aggregation tools like what we have and other > enterprise deployments will want. So I think that commandname is > important to have.
Maybe they can be merged into one value: (cmdname, [fullargs]) so we populate ui less. The pattern is seen in other places like "execve": int execve(const char *path, char *const argv[], char *const envp[]); The first argument "path" is like "cmdname", the unambiguous entry point. Followed by command line arguments. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
