Printing dirty state would require a potentially expensive filesystem operation to see if the working directory is modified. Your shell prompt can either be consistently fast or randomly slow'ish. Pick 1.
FWIW on a clean working directory on my machine: 1000+ms `hg status` or `git status` if the working directory inodes aren't cached 740ms `hg status` 240ms `git status --porcelain` 140ms `hg status` (fsmonitor) 100ms `git status --porcelain --u=no` 60ms `hg status` (fsmonitor+chg) 10ms human perception of instantaneous 5ms scm-prompt.sh YMMV but I find shell prompt lag over say 50ms not tolerable. fsmonitor is the Mercurial extension that uses the watchman file system watching tool to avoid expensive filesystem walks at command time. chg is a C program that spawns a persistent Mercurial process so future commands invocations don't have to create a Python process (creating Python processes typically takes 100ms). chg is still experimental'ish. I use it every day and Facebook uses it in production, so it is pretty stable IMO. More info is at https://www.mercurial-scm.org/wiki/CHg On Mon, Aug 15, 2016 at 8:39 PM, Tim Guan-tin Chien <timdr...@mozilla.com> wrote: > This looks really great until I realized it did not print dirty state. > > There is probably no way to get the state without, say, `git status > --porcelain --u=no`, right? > > On Tue, Aug 16, 2016 at 4:09 AM, Gregory Szorc <g...@mozilla.com> wrote: > >> I use Facebook's scm-prompt.sh from >> https://bitbucket.org/facebook/hg-experimental/src/3a4541379 >> 4a0252a817e7e1fda02182658b85183/scripts/scm-prompt.sh. >> It works with both Git and Mercurial and is fast because it pokes at the >> repo internals directly instead of going through `git` or `hg`. >> >> On Mon, Aug 15, 2016 at 12:46 PM, Botond Ballo <bba...@mozilla.com> >> wrote: >> >> > Cross-posting to dev-version-control >> > >> > On Mon, Aug 15, 2016 at 3:39 PM, <zbranie...@mozilla.com> wrote: >> > > For the last few months I've been mostly using git clone of >> > mozilla-central because I'm used to git. Now I'm trying to set up my >> > mercurial environment to match what I have for git in order to reduce >> the >> > bias toward the latter. >> > > >> > > One of the crucial parts of my workflow is the git completion shell >> > prompt that gives me information about branch I'm on and >> untracked/modified >> > files. >> > > >> > > This is how my shell prompt looks like on gecko-dev (git clone): >> > > >> > > zbraniecki@cintra:~/projects/mozilla/gecko-dev (master %=)$ >> > > >> > > and if I modify any file it may look like this: >> > > >> > > zbraniecki@cintra:~/projects/mozilla/gecko-dev (master +%>)$ >> > > >> > > I tried to get something similar for HG, including hg-prompt (written >> in >> > python), and vcsprompt (written in C), but both are painfully slow. >> > > >> > > What's striking, on the same repo, the git is 3 times faster than hg >> to >> > get me the prompt shell. >> > > >> > > zbraniecki@cintra:~/projects/mozilla/gecko-dev (master %=)$ time >> > vcprompt -f "( %b %u%%%m)" >> > > ( master ?%) >> > > real 0m0.472s >> > > user 0m0.236s >> > > sys 0m0.384s >> > > >> > > vs >> > > >> > > zbraniecki@cintra:~/projects/mozilla/mozilla-central$ time vcprompt >> -f >> > "( %b %u%%%m)" >> > > ( default %+) >> > > real 0m1.643s >> > > user 0m1.224s >> > > sys 0m0.396s >> > > >> > > >> > > I thought that maybe it's just vcprompt, so I tried status: >> > > >> > > zbraniecki@cintra:~/projects/mozilla/mozilla-central$ time hg status >> > > >> > > real 0m1.706s >> > > user 0m1.380s >> > > sys 0m0.316s >> > > >> > > vs. >> > > >> > > zbraniecki@cintra:~/projects/mozilla/gecko-dev (master %=)$ time git >> > status >> > > On branch master >> > > Your branch is up-to-date with 'origin/master'. >> > > >> > > real 0m0.399s >> > > user 0m0.204s >> > > sys 0m0.332s >> > > >> > > If I understand correctly our choice of using mercurial over git was >> > driven by the performance. Am I doing something wrong? >> > > >> > > It seems like the performance difference is quite substantial. >> > > >> > > zb. >> > > _______________________________________________ >> > > dev-platform mailing list >> > > dev-platform@lists.mozilla.org >> > > https://lists.mozilla.org/listinfo/dev-platform >> > _______________________________________________ >> > dev-version-control mailing list >> > dev-version-cont...@lists.mozilla.org >> > https://lists.mozilla.org/listinfo/dev-version-control >> > >> _______________________________________________ >> dev-version-control mailing list >> dev-version-cont...@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-version-control >> > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
