[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