I think you are talking about the "entry point", which is different from
"chg".
At Facebook, "hg" is a wrapper that reads a tiny config file, and calls
either "chg" or "hg.real", where "hg.real" is the "hg" script elsewhere.
So it makes sense to have a very lightweight binary that basically execs
Gregory Szorc writes:
> Currently, chg is its own standalone C program. When invoked, it spawns a
> Python/hg process (if necessary) then talks to it.
>
> A major disadvantage of this approach is that users need to install chg
> (currently separately) and alias it to `hg` in their shell. This mea
Currently, chg is its own standalone C program. When invoked, it spawns a
Python/hg process (if necessary) then talks to it.
A major disadvantage of this approach is that users need to install chg
(currently separately) and alias it to `hg` in their shell. This means
adoption is difficult. chg sho