{"thread":{"id":"33237","subject":"[RFC] Add posibility to preload stat information.","startedAt":"2013-03-20T12:15:32Z","lastAt":"2013-03-30T19:42:07Z","messageCount":13,"participants":["Fredrik Gustafsson","Jeff King","Ramkumar Ramachandra","Junio C Hamano","Thomas Rast","Phil Hord"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"211734","messageId":"1363781732-11396-1-git-send-email-iveqy@iveqy.com","threadId":"33237","inReplyTo":null,"subject":"[RFC] Add posibility to preload stat information.","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-03-20T12:15:32Z","receivedAt":"2013-03-20T12:15:32Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"When entering a git working dir, optionally run a forked process that\nstat all files in the whole workdir and therefore loads stat information\nto RAM which will speedup things like git status and so on.\n\nThe feature is optional and by default it's off.\n\nSigned-off-by: Fredrik Gustafsson <iveqy@iveqy.com>\n---\n contrib/completion/git-prompt.sh | 23 +++++++++++++++++++++++\n 1 file changed, 23 insertions(+)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 341422a..e67bc97 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -78,6 +78,12 @@\n # If you would like a colored hint about the current dirty state, set\n # GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on\n # the colored output of \"git status -sb\".\n+#\n+# When enter a git work dir you can have a forked process run\n+# stat on all files in the top level directory for git and down.\n+# This will decrease later calls to git status and alike because\n+# stat info will already be loaded into RAM. set GIT_PRE_STAT to\n+# a nonempty value.\n \n # __gitdir accepts 0 or 1 arguments (i.e., location)\n # returns location of .git repo\n@@ -222,6 +228,19 @@ __git_ps1_show_upstream ()\n \n }\n \n+# Forks and recursive do a stat from the toplevel git dir.\n+# This will load inodes into RAM for faster access when running\n+# A git command, like git show.\n+__git_recursive_stat ()\n+{\n+\tif test ! -e /tmp/gitbash.lock\n+\tthen\n+\t\ttouch /tmp/gitbash.lock\n+\t\tcd $(git rev-parse --show-toplevel)\n+\t\tfind . | xargs stat 2&> /dev/null\n+\t\trm /tmp/gitbash.lock\n+\tfi\n+}\n \n # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n # when called from PS1 using command substitution\n@@ -320,6 +339,10 @@ __git_ps1 ()\n \t\t\t\tb=\"GIT_DIR!\"\n \t\t\tfi\n \t\telif [ \"true\" = \"$(git rev-parse --is-inside-work-tree 2>/dev/null)\" ]; then\n+\t\t\tif [ -n \"${GIT_PRE_STAT-}\" ];\n+\t\t\tthen\n+\t\t\t\t(__git_recursive_stat 2&> /dev/null &)\n+\t\t\tfi\n \t\t\tif [ -n \"${GIT_PS1_SHOWDIRTYSTATE-}\" ] &&\n \t\t\t   [ \"$(git config --bool bash.showDirtyState)\" != \"false\" ]\n \t\t\tthen\n-- \n1.8.1.5\n"},{"id":"211763","messageId":"20130320164806.GA10752@sigill.intra.peff.net","threadId":"33237","inReplyTo":"1363781732-11396-1-git-send-email-iveqy@iveqy.com","subject":"Re: [RFC] Add posibility to preload stat information.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-20T16:48:06Z","receivedAt":"2013-03-20T16:48:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 20, 2013 at 01:15:32PM +0100, Fredrik Gustafsson wrote:\n\n> When entering a git working dir, optionally run a forked process that\n> stat all files in the whole workdir and therefore loads stat information\n> to RAM which will speedup things like git status and so on.\n> \n> The feature is optional and by default it's off.\n\nKind of gross, but I guess it is useful to some people.\n\n> +__git_recursive_stat ()\n> +{\n> +\tif test ! -e /tmp/gitbash.lock\n> +\tthen\n> +\t\ttouch /tmp/gitbash.lock\n\nThis is a tmp-race security hole. E.g., do:\n\n  ln -s /etc/nologin /tmp/gitbash.lock\n\nas a user; when root runs __git_recursive_stat, it will create\n/etc/nologin. It's not quite as bad as some other holes, because we only\n\"touch\" the file, not overwrite its contents, but you can see that it's\npossible to do some mischief.\n\nShould this maybe just be ~/.gitbash.lock or something?\n\n> +\t\tcd $(git rev-parse --show-toplevel)\n> +\t\tfind . | xargs stat 2&> /dev/null\n\nThe \"stat\" utility is not portable. But why not use git to do the\nreading? Then you can get the benefit of core.preloadindex, and you will\nnot recurse into untracked directories that are ignored (i.e.,\nones that git would not go into anyway).\n\nSo maybe just run \"git status >/dev/null\"?\n\n-Peff\n"},{"id":"211768","messageId":"CALkWK0=b80U5dxGMpwKwL+jFURisEuSapWuuNRFcP+5R2f3+GA@mail.gmail.com","threadId":"33237","inReplyTo":"1363781732-11396-1-git-send-email-iveqy@iveqy.com","subject":"Re: [RFC] Add posibility to preload stat information.","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-20T17:15:22Z","receivedAt":"2013-03-20T17:15:22Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Fredrik Gustafsson wrote:\n> When entering a git working dir, optionally run a forked process that\n> stat all files in the whole workdir and therefore loads stat information\n> to RAM which will speedup things like git status and so on.\n\nThis is misleading.  You just execute the equivalent of `git status`\neverytime I request a prompt inside a git working directory.  And this\nis if I'm using __git_ps1() to augment my prompt, which I'm not- I use\nZSH's vcs_info, which is arguably better.  Also, you forgot to say how\nto turn on the feature.\n\nThat said, this feature is extremely gross; it thrashes my filesystem\nand hard drive.  Modern software is written to minimize IO, not\nmaximize it!  I'm completely against the inclusion of this patch.\n\nHowever, I would not mind a feature that runs `git status` the very\nfirst time I enter a git working directory: when I enter my clone of\nlinux.git, it takes my first `git status` invocation a good ten\nseconds to complete, and we can fix this pretty easily.\n"},{"id":"211769","messageId":"7vhak6f0w4.fsf@alter.siamese.dyndns.org","threadId":"33237","inReplyTo":"20130320164806.GA10752@sigill.intra.peff.net","subject":"Re: [RFC] Add posibility to preload stat information.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-20T17:15:39Z","receivedAt":"2013-03-20T17:15:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> So maybe just run \"git status >/dev/null\"?\n\nIn the background?  How often would it run?  I do not think a single\nlockfile solves anything.  It may prevent simultaneous runs of two\nsuch \"prime the well\" processes, but the same user may be working in\ntwo separate repositories.\n\nI do not see anything that prevents it from running in the same\nrepository over and over again, either.  \"prompt\" is a bad place to\ndo this kind of thing.\n"},{"id":"211773","messageId":"20130320174120.GA32426@paksenarrion.iveqy.com","threadId":"33237","inReplyTo":"CALkWK0=b80U5dxGMpwKwL+jFURisEuSapWuuNRFcP+5R2f3+GA@mail.gmail.com","subject":"Re: [RFC] Add posibility to preload stat information.","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-03-20T17:41:20Z","receivedAt":"2013-03-20T17:41:20Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Wed, Mar 20, 2013 at 10:45:22PM +0530, Ramkumar Ramachandra wrote:\n> Fredrik Gustafsson wrote:\n> > When entering a git working dir, optionally run a forked process that\n> > stat all files in the whole workdir and therefore loads stat information\n> > to RAM which will speedup things like git status and so on.\n> \n> This is misleading.  You just execute the equivalent of `git status`\n> everytime I request a prompt inside a git working directory.  And this\n> is if I'm using __git_ps1() to augment my prompt, which I'm not- I use\n> ZSH's vcs_info, which is arguably better.  Also, you forgot to say how\n> to turn on the feature.\n\nThe invokation place is quesionable (Junio also had some thoughts about\nthat). I don't find vcs_info in the contrib/completition/. Do you have\nany suggestion about where the best way is to inwoke this kind of thing?\n\nI added documentation about how to turn the feature on, in the same way\nthe other features is documented. (Is there an other way/better way I\nshould do this?)\n\n> \n> That said, this feature is extremely gross; it thrashes my filesystem\n> and hard drive.  Modern software is written to minimize IO, not\n> maximize it!  I'm completely against the inclusion of this patch.\n\nIt's extremly gross. I don't like this, _but_ it does speed up my work.\nI'm unsure if it should be included in git though (hence the RFC-tag).\n\n> \n> However, I would not mind a feature that runs `git status` the very\n> first time I enter a git working directory: when I enter my clone of\n> linux.git, it takes my first `git status` invocation a good ten\n> seconds to complete, and we can fix this pretty easily.\n\nThat's the problem I try to solve. However \"the first time\" is\nirrelevant. We will run git status a bit before we need it. If we enter\nlinux.git, do other work (in an other project) for an hour and go back\nto linux.git our cache will probably be empty. We will need to run this\nmore than \"the first time\". But still, we don't want it to run too\noften. (Which is does now).\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"211775","messageId":"20130320174759.GA29349@sigill.intra.peff.net","threadId":"33237","inReplyTo":"7vhak6f0w4.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] Add posibility to preload stat information.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-20T17:47:59Z","receivedAt":"2013-03-20T17:47:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 20, 2013 at 10:15:39AM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > So maybe just run \"git status >/dev/null\"?\n> \n> In the background?  How often would it run?  I do not think a single\n> lockfile solves anything.  It may prevent simultaneous runs of two\n> such \"prime the well\" processes, but the same user may be working in\n> two separate repositories.\n\nYes, in the background (he invokes __git_recursive_stat already in the\nbackground). I'd think you would want to run it whenever you enter a\nrepository.\n\n> I do not see anything that prevents it from running in the same\n> repository over and over again, either.  \"prompt\" is a bad place to\n> do this kind of thing.\n\nYeah, I did not look closely at that. The commit message claims \"When\nentering a git working dir\", but the implementation runs it on each\nprompt invocation, which is awful. I think you'd want to check to use\nrev-parse to see if you have changed into a new git repo, and only run\nit once then.\n\nWhich is still gross, and I have no interest whatsoever in this feature.\nI was just trying to be positive and constructive to the original\nsubmission. :)\n\n-Peff\n"},{"id":"211776","messageId":"CALkWK0nCY3o_KW8ykq9TkzfHeVj6NKDkOFuym9UmSWLH0ZFxBw@mail.gmail.com","threadId":"33237","inReplyTo":"20130320174120.GA32426@paksenarrion.iveqy.com","subject":"Re: [RFC] Add posibility to preload stat information.","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-20T17:49:38Z","receivedAt":"2013-03-20T17:49:38Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Fredrik Gustafsson wrote:\n> On Wed, Mar 20, 2013 at 10:45:22PM +0530, Ramkumar Ramachandra wrote:\n>> Fredrik Gustafsson wrote:\n>> > When entering a git working dir, optionally run a forked process that\n>> > stat all files in the whole workdir and therefore loads stat information\n>> > to RAM which will speedup things like git status and so on.\n>>\n>> This is misleading.  You just execute the equivalent of `git status`\n>> everytime I request a prompt inside a git working directory.  And this\n>> is if I'm using __git_ps1() to augment my prompt, which I'm not- I use\n>> ZSH's vcs_info, which is arguably better.  Also, you forgot to say how\n>> to turn on the feature.\n>\n> The invokation place is quesionable (Junio also had some thoughts about\n> that). I don't find vcs_info in the contrib/completition/. Do you have\n> any suggestion about where the best way is to inwoke this kind of thing?\n\nI think it should be a separate script in contrib/ that people can\njust `eval` in their shell configs; zsh has a chpwd() function for\nexample, which seems like the right place to put such a thing.\n\n> I added documentation about how to turn the feature on, in the same way\n> the other features is documented. (Is there an other way/better way I\n> should do this?)\n\nNo, I meant in the commit message.\n\n>> That said, this feature is extremely gross; it thrashes my filesystem\n>> and hard drive.  Modern software is written to minimize IO, not\n>> maximize it!  I'm completely against the inclusion of this patch.\n>\n> It's extremly gross. I don't like this, _but_ it does speed up my work.\n> I'm unsure if it should be included in git though (hence the RFC-tag).\n\nYes, I would certainly like my git startup time to be improved.  But I\ndon't want to trade my hard drive's life for it.\n\n>> However, I would not mind a feature that runs `git status` the very\n>> first time I enter a git working directory: when I enter my clone of\n>> linux.git, it takes my first `git status` invocation a good ten\n>> seconds to complete, and we can fix this pretty easily.\n>\n> That's the problem I try to solve. However \"the first time\" is\n> irrelevant. We will run git status a bit before we need it. If we enter\n> linux.git, do other work (in an other project) for an hour and go back\n> to linux.git our cache will probably be empty. We will need to run this\n> more than \"the first time\". But still, we don't want it to run too\n> often. (Which is does now).\n\nWhat I meant by \"first time\" is \"chpwd() into the git repository, not\nfurther chpwd()s when already inside the git repository\".\n"},{"id":"211790","messageId":"20130320183641.GB32426@paksenarrion.iveqy.com","threadId":"33237","inReplyTo":"CALkWK0nCY3o_KW8ykq9TkzfHeVj6NKDkOFuym9UmSWLH0ZFxBw@mail.gmail.com","subject":"Re: [RFC] Add posibility to preload stat information.","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-03-20T18:36:41Z","receivedAt":"2013-03-20T18:36:41Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Wed, Mar 20, 2013 at 11:19:38PM +0530, Ramkumar Ramachandra wrote:\n> I think it should be a separate script in contrib/ that people can\n> just `eval` in their shell configs; zsh has a chpwd() function for\n> example, which seems like the right place to put such a thing.\n\nI was trying to spare the number of calls to \"git rev-parse\n--is-inside-work-tree\". But maybe that is to fast to care about.\n\n> No, I meant in the commit message.\n\nOkay, thanks.\n\n> >> That said, this feature is extremely gross; it thrashes my filesystem\n> >> and hard drive.  Modern software is written to minimize IO, not\n> >> maximize it!  I'm completely against the inclusion of this patch.\n> >\n> > It's extremly gross. I don't like this, _but_ it does speed up my work.\n> > I'm unsure if it should be included in git though (hence the RFC-tag).\n> \n> Yes, I would certainly like my git startup time to be improved.  But I\n> don't want to trade my hard drive's life for it.\n\nDoes this really increase disk-reads? The fs-cache would make sure that\nthe disk reads is almost the same, we only do them before we usually do\nthem.\n\n> What I meant by \"first time\" is \"chpwd() into the git repository, not\n> further chpwd()s when already inside the git repository\".\n\nThat's a good point. I'm not sure how to solve that though. Because it's\nnot a fact that you always go to the root git-dir first.\n\nThe only way I see this is with a lock-file that's kept and we only run\ngit status every 5 minutes when doing something inside a work dir. That\nwould add a lot of meta-data (the lock files), to store. (I hope I\nsuccessfully explained that).\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"211793","messageId":"20130320184032.GC32426@paksenarrion.iveqy.com","threadId":"33237","inReplyTo":"20130320164806.GA10752@sigill.intra.peff.net","subject":"Re: [RFC] Add posibility to preload stat information.","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-03-20T18:40:32Z","receivedAt":"2013-03-20T18:40:32Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Wed, Mar 20, 2013 at 12:48:06PM -0400, Jeff King wrote:\n> Kind of gross, but I guess it is useful to some people.\n\nYes it is. The questions is if it's gross enough to never\nleave my computer, or if someone else can find this useful.\n\n> \n> > +__git_recursive_stat ()\n> > +{\n> > +\tif test ! -e /tmp/gitbash.lock\n> > +\tthen\n> > +\t\ttouch /tmp/gitbash.lock\n> \n> This is a tmp-race security hole. E.g., do:\n> \n>   ln -s /etc/nologin /tmp/gitbash.lock\n> \n> as a user; when root runs __git_recursive_stat, it will create\n> /etc/nologin. It's not quite as bad as some other holes, because we only\n> \"touch\" the file, not overwrite its contents, but you can see that it's\n> possible to do some mischief.\n> \n> Should this maybe just be ~/.gitbash.lock or something?\n\nThank you! I totally missed that.\n\nI guess a new solution would be to keep an access time-stamp in each\nrepository and with certain intervall run git status on that repository.\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"211797","messageId":"20130320184643.GA30165@sigill.intra.peff.net","threadId":"33237","inReplyTo":"20130320183641.GB32426@paksenarrion.iveqy.com","subject":"Re: [RFC] Add posibility to preload stat information.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-20T18:46:43Z","receivedAt":"2013-03-20T18:46:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 20, 2013 at 07:36:41PM +0100, Fredrik Gustafsson wrote:\n\n> > Yes, I would certainly like my git startup time to be improved.  But I\n> > don't want to trade my hard drive's life for it.\n> \n> Does this really increase disk-reads? The fs-cache would make sure that\n> the disk reads is almost the same, we only do them before we usually do\n> them.\n\nIt shouldn't. But if you are running \"stat\" on every file in the repo\nfor each prompt, that is going to take measurable CPU time for large\nrepos (e.g., WebKit).\n\n> > What I meant by \"first time\" is \"chpwd() into the git repository, not\n> > further chpwd()s when already inside the git repository\".\n> \n> That's a good point. I'm not sure how to solve that though. Because it's\n> not a fact that you always go to the root git-dir first.\n> \n> The only way I see this is with a lock-file that's kept and we only run\n> git status every 5 minutes when doing something inside a work dir. That\n> would add a lot of meta-data (the lock files), to store. (I hope I\n> successfully explained that).\n\nHow about something like:\n\n  __git_primed_toplevel=\n  __git_prime_dir() {\n          local toplevel=`git rev-parse --show-toplevel 2>/dev/null`\n          if test -n \"$toplevel\" &&\n             test \"$toplevel\" != \"$git_primed_toplevel\"; then\n                  git status >/dev/null 2>&1\n                  git_primed_toplevel=$toplevel\n          fi\n  }\n\nthat would prime the whole repo the first time you enter it, but otherwise do\nnothing (and you could run it from each prompt). If you switched back and forth\nbetween two repos a lot, you would end up priming them both a lot, but that is\nnot that common a mode of operation (and you could keep an list of recently\nprimed repos instead of a single one, if you really wanted to deal with that).\nYou would also prime twice if you used two different terminals, but that's OK.\nThe subsequent ones are much faster due to disk cache, so this is really just\nabout not paying the extra stat penalty on _every_ prompt.\n\n-Peff\n"},{"id":"211845","messageId":"87vc8lyqz7.fsf@pctrast.inf.ethz.ch","threadId":"33237","inReplyTo":"20130320174759.GA29349@sigill.intra.peff.net","subject":"Re: [RFC] Add posibility to preload stat information.","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2013-03-21T10:41:48Z","receivedAt":"2013-03-21T10:41:48Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Mar 20, 2013 at 10:15:39AM -0700, Junio C Hamano wrote:\n>\n>> Jeff King <peff@peff.net> writes:\n>> \n>> > So maybe just run \"git status >/dev/null\"?\n>> \n>> In the background?  How often would it run?  I do not think a single\n>> lockfile solves anything.  It may prevent simultaneous runs of two\n>> such \"prime the well\" processes, but the same user may be working in\n>> two separate repositories.\n>\n> Yes, in the background (he invokes __git_recursive_stat already in the\n> background). I'd think you would want to run it whenever you enter a\n> repository.\n>\n>> I do not see anything that prevents it from running in the same\n>> repository over and over again, either.  \"prompt\" is a bad place to\n>> do this kind of thing.\n>\n> Yeah, I did not look closely at that. The commit message claims \"When\n> entering a git working dir\", but the implementation runs it on each\n> prompt invocation, which is awful. I think you'd want to check to use\n> rev-parse to see if you have changed into a new git repo, and only run\n> it once then.\n\nI think it would actually be a somewhat interesting feature if it\ninteracted with GIT_PS1_SHOW*.  If you use these settings (I personally\nuse SHOWDIRTYSTATE but not SHOWUNTRACKEDFILES), the prompt hangs while\n__git_ps1 runs git-status.  It should be possible to run a git-status\nprocess in the background when entering a repository, and displaying\nsome marker ('??' maybe) in the prompt instead of the dirty-state info\nuntil git-status has finished.  That way the user doesn't have his shell\nblocked by cding to a big repo.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"211869","messageId":"7vtxo4byng.fsf@alter.siamese.dyndns.org","threadId":"33237","inReplyTo":"87vc8lyqz7.fsf@pctrast.inf.ethz.ch","subject":"Re: [RFC] Add posibility to preload stat information.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-21T14:44:35Z","receivedAt":"2013-03-21T14:44:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <trast@student.ethz.ch> writes:\n\n> I think it would actually be a somewhat interesting feature if it\n> interacted with GIT_PS1_SHOW*.  If you use these settings (I personally\n> use SHOWDIRTYSTATE but not SHOWUNTRACKEDFILES), the prompt hangs while\n> __git_ps1 runs git-status.  It should be possible to run a git-status\n> process in the background when entering a repository, and displaying\n> some marker ('??' maybe) in the prompt instead of the dirty-state info\n> until git-status has finished.\n\nThis is somewhat interesting.\n\nPerhaps we can introduce a helper binary that does what __git_ps1()\ndoes, with a --timeout=500ms option to say \"I dunno (yet)\", and keep\npriming the well in the background when it takes more than the\nspecified amount of time?\n"},{"id":"212708","messageId":"CABURp0rAp_s1jDdhohZ44+6RXNW_A4JirAaVwfiCL9Jf2ZmiZA@mail.gmail.com","threadId":"33237","inReplyTo":"7vtxo4byng.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] Add posibility to preload stat information.","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-03-30T19:42:07Z","receivedAt":"2013-03-30T19:42:07Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Thu, Mar 21, 2013 at 10:44 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Thomas Rast <trast@student.ethz.ch> writes:\n>\n>> I think it would actually be a somewhat interesting feature if it\n>> interacted with GIT_PS1_SHOW*.  If you use these settings (I personally\n>> use SHOWDIRTYSTATE but not SHOWUNTRACKEDFILES), the prompt hangs while\n>> __git_ps1 runs git-status.  It should be possible to run a git-status\n>> process in the background when entering a repository, and displaying\n>> some marker ('??' maybe) in the prompt instead of the dirty-state info\n>> until git-status has finished.\n>\n> This is somewhat interesting.\n>\n> Perhaps we can introduce a helper binary that does what __git_ps1()\n> does, with a --timeout=500ms option to say \"I dunno (yet)\", and keep\n> priming the well in the background when it takes more than the\n> specified amount of time?\n\nThat would be nice.  My fork-fu is weak, so I cheated and relied on\nkill/timeout instead.\n\nI have had this code below in my zsh git prompt (based on oh-my-zsh)\nfor more than a year.  It uses $(timeout) to kill the status command\nif it does not complete in 1 second.  It's dumb in several ways, but\nit does show me four different flags fairly reliably indicating\nwhether I have changed files, untracked files, clean workdir, or I\ntimed out trying to find out.\n\ngit_dirty_timeout () {\n  #-- Modified files\n  xx=$(timeout 1s git status -s $@ 2> /dev/null)\n  test $? -eq 124 && return 124\n  test -n ${xx} && return 50\n\n  #-- Untracked files (only)\n  xx=$(timeout 1s git status -s -uno $@ 2> /dev/null)\n  test $? -eq 124 && return 124\n  test -n ${xx} && return 51\n  return 0\n}\n\nparse_git_dirty () {\n  git_dirty_timeout\n  case \"$?\" in\n        '50')  echo \"$ZSH_THEME_GIT_PROMPT_DIRTY\"       ;;\n        '51')  echo \"$ZSH_THEME_GIT_PROMPT_UNTRACKED\"   ;;\n        '124') echo \"$ZSH_THEME_GIT_PROMPT_TIMEOUT\"     ;;\n        *)     echo \"[$?]$ZSH_THEME_GIT_PROMPT_CLEAN\"   ;;\n  esac\n}\n"}]}