[PATCH 3 of 3] localrepo: pass args and command running as store/write lock metadata
Jun Wu
quark at fb.com
Tue Mar 21 16:45:32 EDT 2017
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.
More information about the Mercurial-devel
mailing list