| Message ID | pull.1384.v2.git.1667002005494.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] status: long status advice adapted to recent capabilities | expand |
On 10/28/22 8:06 PM, Rudy Rigot via GitGitGadget wrote: > From: Rudy Rigot <rudy.rigot@gmail.com> > > Currently, if git-status takes more than 2 seconds for enumerating untracked > files, a piece of advice is given to the user to consider ignoring untracked > files. But Git now offers more possibilities to resolve that situation > (untracked cache, fsmonitor) with different downsides. > > This change is about refreshing that advice message. A new section in the > documentation is introduced to present the possibilities, and the advice > message links to it. I'm also introducing tests for this advice message, > which was untested so far. > > One of the downsides of untracked cache / fsmonitor, is that the first call > may be long in order to generate the cache, but the user may not know what > their current configuration is. When collecting feedback from users of our > very large repo, that's the most common point of confusion that keeps coming > back: people complain about git status being slow, but are satisfied when > we inform them that it's being cached and they should run it again to check. > As a result, the advice message tries to keep them informed of their current > configuration. Let me suggest an alternative commit message. We want to lead with a "command" -- as in: "make Git do this" or "teach Git to do this". Then explain why. Maybe something like: Improve the advice displayed when `git status` is slow because of excessive numbers of untracked files. Update the `git status` man page to explain the various configuration options. `git status` can be slow when there are a large number of untracked files and directories, because Git must search the entire worktree to enumerate them. Previously, Git would print an advice message with the elapsed search time and a suggestion to disable the search using the `-uno` option. This suggestion also carried a warning that might scare off some users. Git can reduce the size and time of the untracked file search when the `core.untrackedCache` and `core.fsmonitor` features are enabled by caching results from previous `git status` invocations. Update the advice to explain the various combinations of additional configuration options and refer to (new) documentation in the man page that explains it in more detail than what can be printed in an advice message. Finally, add new tests to verify the new functionality. Or something like that. :-) [...] > diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt > index 54a4b29b473..3d92e5fd018 100644 > --- a/Documentation/git-status.txt > +++ b/Documentation/git-status.txt > @@ -457,6 +457,33 @@ during the write may conflict with other simultaneous processes, causing > them to fail. Scripts running `status` in the background should consider > using `git --no-optional-locks status` (see linkgit:git[1] for details). > > +UNTRACKED FILES AND STATUS SPEED > +-------------------------------- > + > +If your untracked files take an unusual amount of time to enumerate, your > +repository certainly has a lot of them, and an advice message will display > +about it. Here are some configurations to consider in order to improve the > +situation: > + > +* Setting the `core.untrackedCache` configuration as `true` will allow for > +`git status` to keep track of the mtime of folders, in order to cache past > +`status` results and be sure to only browse folders that changed on subsequent > +runs, for filesystems that can support it (see linkgit:git-update-index[1] > +for details). > +* Used in conjonction with `core.untrackedCache`, setting the `core.fsmonitor` > +configuration as `true` will allow for `git status` to keep track of what > +files recently changed, in order to cache past `status` results and be sure > +to only focus on those files on subsequent runs (see linkgit:git-update-index[1] > +for details). > +* If none of the above options are satisfactory, setting the > +`status.showUntrackedFiles` configuration as `no` will cause `git status` > +to not attempt to list untracked files anymore, in which case you have to be > +careful not to forget to add new files yourself. > + > +If none of the above solutions are satisfactory, and you are bothered with > +the advice message, you can disable it by setting the `advice.statusUoption` > +configuration to `false`. > + I hate to suggest a complete rewrite as I myself struggle with how to phrase things all toooooo often, but let me offer another starting point and see what you think: `git status` can be very slow in large worktrees if/when it needs to search for untracked files and directories. There are many configuration options available to speed this up by either avoiding the work or making use of cached results from previous Git commands. Since we all work in different ways, there is no single optimum set of settings right for everyone. Here is a brief summary of the relevant options to help you choose which is right for you. Each of these settings is independently documented elsewhere in more detail, so please refer to them for complete details. * `-uno` or `status.showUntrackedFiles=false` : just don't search and don't report on untracked files. This is the fastest. `git status` will not list the untracked files, so you need to be careful to remember if you create any new files and manually `git add` them. * `advice.statusUoption=false` : search, but don't complain if it takes too long. * `core.untrackedCache=true` : enable the untracked cache feature and only search directories that have been modified since the previous `git status` command. Git remembers the set of untracked files within each directory and assumes that if a directory has not been modified, then the set of untracked file within has not changed. This is much faster than enumerating the contents of every directory, but still not without cost, because Git still has to search for the set of modified directories. * `core.untrackedCache=true` and `core.fsmonitor=true` or `core.fsmonitor=<hook_command_pathname>` : enable both the untracked cache and FSMonitor features and only search directories that have been modified since the previous `git status` command. This is faster than using just the untracked cache alone because Git can also avoid searching for modified directories. Git only has to enumerate the exact set of directories that have changed recently. Note that after you turn on the untracked cache and/or FSMonitor features it may take a few `git status` commands for the various caches to warm up before you see improved command times. This is normal. Something like that. Hope this helps. (And again, sorry for the rewrite.) [...] > diff --git a/t/t7065-wtstatus-slow.sh b/t/t7065-wtstatus-slow.sh > new file mode 100755 > index 00000000000..92c053eaa64 > --- /dev/null > +++ b/t/t7065-wtstatus-slow.sh > @@ -0,0 +1,40 @@ > +#!/bin/sh [...] > + > +test_done > \ No newline at end of file small nit: we should have a final LF at the end of the file. I'm going to skip over the test cases because I'm running short on time this afternoon. [...] > diff --git a/wt-status.c b/wt-status.c [...] > static void show_merge_in_progress(struct wt_status *s, > const char *color) > { > @@ -1814,6 +1827,7 @@ static void wt_longstatus_print(struct wt_status *s) > { > const char *branch_color = color(WT_STATUS_ONBRANCH, s); > const char *branch_status_color = color(WT_STATUS_HEADER, s); > + enum fsmonitor_mode fsm_mode = fsm_settings__get_mode(s->repo); > > if (s->branch) { > const char *on_what = _("On branch "); > @@ -1870,13 +1884,25 @@ static void wt_longstatus_print(struct wt_status *s) > wt_longstatus_print_other(s, &s->untracked, _("Untracked files"), "add"); > if (s->show_ignored_mode) > wt_longstatus_print_other(s, &s->ignored, _("Ignored files"), "add -f"); > - if (advice_enabled(ADVICE_STATUS_U_OPTION) && 2000 < s->untracked_in_ms) { > - status_printf_ln(s, GIT_COLOR_NORMAL, "%s", ""); > - status_printf_ln(s, GIT_COLOR_NORMAL, > - _("It took %.2f seconds to enumerate untracked files. 'status -uno'\n" > - "may speed it up, but you have to be careful not to forget to add\n" > - "new files yourself (see 'git help status')."), > - s->untracked_in_ms / 1000.0); > + if (uf_was_slow(s->untracked_in_ms)) { > + if (advice_enabled(ADVICE_STATUS_U_OPTION)) { > + status_printf_ln(s, GIT_COLOR_NORMAL, "%s", ""); > + if (s->repo->settings.core_untracked_cache == UNTRACKED_CACHE_WRITE) { > + status_printf_ln(s, GIT_COLOR_NORMAL, > + _("It took %.2f seconds to enumerate untracked files,\n" > + "but this is currently being cached, with fsmonitor %s."), > + s->untracked_in_ms / 1000.0, > + (fsm_mode > FSMONITOR_MODE_DISABLED) ? "ON" : "OFF"); > + } else { > + status_printf_ln(s, GIT_COLOR_NORMAL, > + _("It took %.2f seconds to enumerate untracked files."), > + s->untracked_in_ms / 1000.0); > + } > + status_printf_ln(s, GIT_COLOR_NORMAL, > + _("See https://git-scm.com/docs/git-status#_untracked_files_and_status_speed\n" > + "for configuration options that may improve that time.")); > + status_printf_ln(s, GIT_COLOR_NORMAL, "%s", ""); > + } I'm not sure I like the various mixture of messages here. Maybe it would be better with a single simple message: _("It took %.2f seconds to enumerate untracked files.\n" "See 'git help status' for information on how to improve this.") This keeps all of the information in the documentation rather than having part of it here in the code. Also, we should refer to the documentation via `git help` rather than as a link to the website. Thanks, Jeff
Thanks a lot for all that feedback. Honestly you're way more familiar than I am with both how the underlying features work, and how to best contribute this change, so I'm comfortable taking your advice pretty much blindly. > Let me suggest an alternative commit message. We want to lead with a > "command" -- as in: "make Git do this" or "teach Git to do this". Then > explain why. Oops, sorry for missing this. Well, your commit message suggestion is flawless, I will reuse this as is. Thanks a lot for spending time polishing it. > I hate to suggest a complete rewrite > [...] > Something like that. Hope this helps. (And again, sorry for the rewrite.) There's absolutely nothing to apologize about. This is great! I will also reuse as is. Here too, thanks a lot for the time spent on this! > small nit: we should have a final LF at the end of the file. Sounds good, will fix. > I'm going to skip over the test cases because I'm running > short on time this afternoon. That's all good, I need to align my submission to all this and resubmit anyway, so you got time! I'm pretty confident about them too, a lot more than in the phrasing of the user-facing content I had. > Also, we should refer to the documentation via `git help` rather > than as a link to the website. Oops, I didn't realize people were getting the same content from either. I will fix. > I'm not sure I like the various mixture of messages here. Maybe > it would be better with a single simple message: That's the one thing I'm a bit concerned about, that I would like to discuss more if that's ok. The current confusion we're seeing with users of our very large repo, is that they run git status the first time and notice it being slow (~30s), and then they see the current advice message advising that they're supposed to do something about it. What they don't know, is that untrackedcache and fsmonitor were already set for their environment, by the script setting their entire environment up. I don't think it is unusual for users to not necessarily know how their environment was configured (either because someone/something else did it for them, or because they forgot what they did for this specific repo, for instance). So with that, I worry about the phrasing "See 'git help status' for information on how to improve this." in that use case, because it implies that there is something they are expected to go improve, while that was already done. Here are some solution ideas: * Changing the wording for all use cases to not convey that they must do anything about it. For instance just "See 'git help status'". (I don't love this because I could imagine users being puzzled about why Git is telling them this, then.) * Informing the user of their current caching situation in ways that they can deduce whether or not they should be doing something about it. That's what I was attempting to do here, but reading your help content, I think I got something wrong: I didn't realize the cache would only need to warm up with untrackedcache + fsmonitor, and not with untrackedcache alone. So with that an improvement could be to only display "but this is currently being cached." when both untrackedcache + fsmonitor are on, and not display anything different when only untrackedcache is on then when it's not. * Not displaying this advice message when fsmonitor is on, since the best possible optimization was already applied. Not loving it, because some could also still want untracked files off on top of it. Also, it doesn't resolve the frustration of noticing git status being slow the first time. For now if you don't mind, I'll change things to the 2nd proposal up there, but this is not because I'm rejecting your guidance and insisting that adding a line here is the right solution to the situation of environments that were already optimized, and I'm not sure what is. But I do worry that telling those users that they should optimize things while they/someone already did will surely be confusing. I'll work on the other fixes, and I am deeply interested in your thoughts about this one. Thanks a lot for working through this with me.
On Wed, Nov 02, 2022 at 03:45:18PM -0400, Jeff Hostetler wrote: > Let me suggest an alternative commit message. We want to lead with a > "command" -- as in: "make Git do this" or "teach Git to do this". Then > explain why. Maybe something like: > > [...] Excellent suggestions, thank you. > > @@ -1870,13 +1884,25 @@ static void wt_longstatus_print(struct wt_status *s) > > wt_longstatus_print_other(s, &s->untracked, _("Untracked files"), "add"); > > if (s->show_ignored_mode) > > wt_longstatus_print_other(s, &s->ignored, _("Ignored files"), "add -f"); > > - if (advice_enabled(ADVICE_STATUS_U_OPTION) && 2000 < s->untracked_in_ms) { > > - status_printf_ln(s, GIT_COLOR_NORMAL, "%s", ""); > > - status_printf_ln(s, GIT_COLOR_NORMAL, > > - _("It took %.2f seconds to enumerate untracked files. 'status -uno'\n" > > - "may speed it up, but you have to be careful not to forget to add\n" > > - "new files yourself (see 'git help status')."), > > - s->untracked_in_ms / 1000.0); > > + if (uf_was_slow(s->untracked_in_ms)) { > > + if (advice_enabled(ADVICE_STATUS_U_OPTION)) { > > + status_printf_ln(s, GIT_COLOR_NORMAL, "%s", ""); > > + if (s->repo->settings.core_untracked_cache == UNTRACKED_CACHE_WRITE) { > > + status_printf_ln(s, GIT_COLOR_NORMAL, > > + _("It took %.2f seconds to enumerate untracked files,\n" > > + "but this is currently being cached, with fsmonitor %s."), > > + s->untracked_in_ms / 1000.0, > > + (fsm_mode > FSMONITOR_MODE_DISABLED) ? "ON" : "OFF"); > > + } else { > > + status_printf_ln(s, GIT_COLOR_NORMAL, > > + _("It took %.2f seconds to enumerate untracked files."), > > + s->untracked_in_ms / 1000.0); > > + } > > + status_printf_ln(s, GIT_COLOR_NORMAL, > > + _("See https://git-scm.com/docs/git-status#_untracked_files_and_status_speed\n" > > + "for configuration options that may improve that time.")); > > + status_printf_ln(s, GIT_COLOR_NORMAL, "%s", ""); > > + } > > I'm not sure I like the various mixture of messages here. Maybe > it would be better with a single simple message: > > _("It took %.2f seconds to enumerate untracked files.\n" > "See 'git help status' for information on how to improve this.") > > This keeps all of the information in the documentation rather > than having part of it here in the code. > > Also, we should refer to the documentation via `git help` rather > than as a link to the website. I agree with your suggestion of not linking out to git-scm.com here, but I wonder if we could get by without mentioning 'git help' here, either. Presumably looking up an unknown configuration variable with 'man git-config' is easy enough. Thanks, Taylor
> looking up an unknown configuration variable with 'man > git-config' is easy enough. I'm not strongly opinionated, but I believe the initial idea behind redirecting them to the doc was because Git now comes with more configuration abilities to improve performance of git status, that may be more or less relevant depending on use cases, so there isn't really a single git-config key for them to look up any more. Their ideal solution could be core.untrackedCache=true, core.fsmonitor=true, advice.statusUoption=false, status.showUntrackedFiles=false, or even some combinations of those can be relevant. From there, the goal I believe we were going for with this new doc section is to let users know what configs exist for their git status slowness pains and why, so they can then go look those configs up for more details, which I agree would indeed be easy from there. Again, I'm not strongly opinionated, and I hope I accurately represented the inital thinking on this idea. One slightly stronger opinion I have, is that if the advice message was just > It took %.2f seconds to enumerate untracked files. and nothing else, I can definitely see a strong UX downside of not giving a hint of next steps for users. Basically, "you have a problem, and we're not helping you resolve it". Were you thinking more of something like this? > It took %.2f seconds to enumerate untracked files. > Please look up the core.untrackedCache, core.fsmonitor > advice.statusUoption, and status.showUntrackedFiles configs > for potential solutions. I'd say that's probably somewhat cryptic and a bit verbose (which is what we were trying to avoid by telling them to go see the doc), but we wouldn't be leaving the user stranded, so I can see how that would work out ok. I'm very interested in what you think. Thanks,
On Thu, Nov 03 2022, Rudy Rigot wrote: >> looking up an unknown configuration variable with 'man >> git-config' is easy enough. > > I'm not strongly opinionated, but I believe the initial idea behind > redirecting them to the doc was because Git now comes with more > configuration abilities to improve performance of git status, that may > be more or less relevant depending on use cases, so there > isn't really a single git-config key for them to look up any more. Their > ideal solution could be core.untrackedCache=true, core.fsmonitor=true, > advice.statusUoption=false, status.showUntrackedFiles=false, or even > some combinations of those can be relevant. > > From there, the goal I believe we were going for with this new doc > section is to let users know what configs exist for their git status > slowness pains and why, so they can then go look those configs up for > more details, which I agree would indeed be easy from there. > > Again, I'm not strongly opinionated, and I hope I accurately represented > the inital thinking on this idea. > > One slightly stronger opinion I have, is that if the advice message > was just > >> It took %.2f seconds to enumerate untracked files. > > and nothing else, I can definitely see a strong UX downside of not > giving a hint of next steps for users. Basically, "you have a problem, > and we're not helping you resolve it". Were you thinking more of > something like this? > >> It took %.2f seconds to enumerate untracked files. >> Please look up the core.untrackedCache, core.fsmonitor >> advice.statusUoption, and status.showUntrackedFiles configs >> for potential solutions. > > I'd say that's probably somewhat cryptic and a bit verbose (which is > what we were trying to avoid by telling them to go see the doc), but > we wouldn't be leaving the user stranded, so I can see how that would > work out ok. > > I'm very interested in what you think. On the topic in general: I think it's probably a good thing to show the advice, but I just want to point out that it's not without cost. Right now we're showing users a pretty basic command they can try, but now we're showing them other stuff that needs more complex setup. For some they're probably way better off, e.g. the untracked cache is pretty much an unambiguous win (we should probably turn it on on default, but we'd need to check on-the-fly if the FS supports it properly). But for e.g. fsmonitor the user may spend a lot of time fiddling with it, only to find it doesn't help their use-case much, if it all. Should we still point out these possibilities? Probably, but just say'n. One thing that I find glaringly omitted, which since you're working on this you might consider adding: Suggest to just try running the exact same command again, maybe it was just the FS cache. I.e. we're suggesting all this advanced stuff, but by far the biggest difference is made on e.g. a modern *nix box (particularly Linux) by just having all the repo's assets in the FS cache.
> One thing that I find glaringly omitted, which since you're working on > this you might consider adding: Suggest to just try running the exact > same command again, maybe it was just the FS cache. I have to admit that would be by far my personal preference. We've been having a number of very great points made by several people on this thread, but a number of them contradicting each other across people, and yet clearly nobody's wrong, everybody makes very real points. I'm trying to turn this into actionable changes I should make, but I think I need guidance on that. This is my first ever contribution to the project, so I'm lacking the organizational awareness of the project to be able to drive this to a consensus on what we should do. Here's a proposal that tries to make opinionated moves towards what I understand to be the priorities that were expressed: 1- We keep the new paragraph doc, because I'd say why not, it's well-written (thanks Jeff!) and useful. When people are looking for ways to make git status faster, it's good that there's a reference about it, and I'd expect it to be a common need across all kinds of user situations. 2- When untracked cache is not on, if I understand Ævar's suggestion, it would say something like: > It took %.2f seconds to enumerate untracked files. > Try to enable untracked cache to see if it helps make it faster > for you: > git config core.untrackedCache true It would satisfy that the message gives concise advice with actionable next steps, without making assumptions about whether it will or won't work. (Untracked cache alone did not make much of a difference in our very large repo's case.) And it doesn't point to the help anymore, in order not to saturate the user with too much detail. 3- When untrackedcache is on but fsmonitor is off, and git status is still slow (that's the situation we had on our very large repo), it could say something like: > It took %.2f seconds to enumerate untracked files. > Try to enable FSMonitor to see if it helps make it faster for you: > git config core.fsmonitor true Same as before, concise, no assumptions. This setup is more advanced, but we are in a case where untracked cache is not helping, so I'm thining that should be very few repos. If the user feels a need to better understand what's up, the feature is mentioned by name, so they can look it up and dig in if they wish to. 4- When fsmonitor is on: > It took %.2f seconds to enumerate untracked files. > Your runs are being cached, try running git status again to see if > it's faster. Same as before, concise, no assumptions, and matches Ævar's suggestion above that was also my preference, as it would apply perfectly to our very large repo's use case and the grievances we've received. Please let me know what your thoughts are about it all. A downside with all that is the option to disable untracked files is not mentioned at all, but if we keep the doc as it is, and it gets painful enough that they search for other ways, I'm hopefuly the user would find it there. I want to say it again: I'm not very opinionated about any of this, just trying to collate feedback into an actionable plan. If I understood feedback wrong, or my plan is not the best based on the feedback, that is very fine, but I will need guidance to know what makes more sense. > the untracked cache is > pretty much an unambiguous win (we should probably turn it on on > default, but we'd need to check on-the-fly if the FS supports it > properly). I could take on the work to make untracked cache on by default after this, as another patch, if it sounds relevant to try. I feel I lack the technical understanding of what we need to check that you're mentioning here, so I'll have questions, but I'd be on board with trying.
On Thu, Nov 03, 2022 at 09:28:56AM -0500, Rudy Rigot wrote: > One slightly stronger opinion I have, is that if the advice message > was just > > > It took %.2f seconds to enumerate untracked files. > > and nothing else, I can definitely see a strong UX downside of not > giving a hint of next steps for users. Basically, "you have a problem, > and we're not helping you resolve it". Were you thinking more of > something like this? > > > It took %.2f seconds to enumerate untracked files. > > Please look up the core.untrackedCache, core.fsmonitor > > advice.statusUoption, and status.showUntrackedFiles configs > > for potential solutions. > > I'd say that's probably somewhat cryptic and a bit verbose (which is > what we were trying to avoid by telling them to go see the doc), but > we wouldn't be leaving the user stranded, so I can see how that would > work out ok. > > I'm very interested in what you think. I see what you're saying. On the one hand, it feels redundant to say, "we noticed 'git status' is running slowly for you, try running 'git help status' to figure out why". But on the other hand, enumerating all possible configuration values that you may or may not want to set given your particular circumstance isn't practical either. Thinking on it more, I think what you wrote originally is reasonable. Thanks, Taylor
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index 54a4b29b473..3d92e5fd018 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -457,6 +457,33 @@ during the write may conflict with other simultaneous processes, causing them to fail. Scripts running `status` in the background should consider using `git --no-optional-locks status` (see linkgit:git[1] for details). +UNTRACKED FILES AND STATUS SPEED +-------------------------------- + +If your untracked files take an unusual amount of time to enumerate, your +repository certainly has a lot of them, and an advice message will display +about it. Here are some configurations to consider in order to improve the +situation: + +* Setting the `core.untrackedCache` configuration as `true` will allow for +`git status` to keep track of the mtime of folders, in order to cache past +`status` results and be sure to only browse folders that changed on subsequent +runs, for filesystems that can support it (see linkgit:git-update-index[1] +for details). +* Used in conjonction with `core.untrackedCache`, setting the `core.fsmonitor` +configuration as `true` will allow for `git status` to keep track of what +files recently changed, in order to cache past `status` results and be sure +to only focus on those files on subsequent runs (see linkgit:git-update-index[1] +for details). +* If none of the above options are satisfactory, setting the +`status.showUntrackedFiles` configuration as `no` will cause `git status` +to not attempt to list untracked files anymore, in which case you have to be +careful not to forget to add new files yourself. + +If none of the above solutions are satisfactory, and you are bothered with +the advice message, you can disable it by setting the `advice.statusUoption` +configuration to `false`. + SEE ALSO -------- linkgit:gitignore[5] diff --git a/t/t7065-wtstatus-slow.sh b/t/t7065-wtstatus-slow.sh new file mode 100755 index 00000000000..92c053eaa64 --- /dev/null +++ b/t/t7065-wtstatus-slow.sh @@ -0,0 +1,40 @@ +#!/bin/sh + +test_description='test status when slow untracked files' + +. ./test-lib.sh + +DATA="$TEST_DIRECTORY/t7065" + +GIT_TEST_UF_DELAY_WARNING=1 +export GIT_TEST_UF_DELAY_WARNING + +test_expect_success setup ' + git checkout -b test +' + +test_expect_success 'when core.untrackedCache and fsmonitor are unset' ' + test_must_fail git config --get core.untrackedCache && + test_must_fail git config --get core.fsmonitor && + git status | sed "s/[0-9]\.[0-9][0-9]/X/g" >../actual && + test_cmp "$DATA/no_untrackedcache_no_fsmonitor" ../actual && + rm -fr ../actual +' + +test_expect_success 'when core.untrackedCache true, but not fsmonitor' ' + git config core.untrackedCache true && + test_must_fail git config --get core.fsmonitor && + git status | sed "s/[0-9]\.[0-9][0-9]/X/g" >../actual && + test_cmp "$DATA/with_untrackedcache_no_fsmonitor" ../actual && + rm -fr ../actual +' + +test_expect_success 'when core.untrackedCache true, and fsmonitor' ' + git config core.untrackedCache true && + git config core.fsmonitor true && + git status | sed "s/[0-9]\.[0-9][0-9]/X/g" >../actual && + test_cmp "$DATA/with_untrackedcache_with_fsmonitor" ../actual && + rm -fr ../actual +' + +test_done \ No newline at end of file diff --git a/t/t7065/no_untrackedcache_no_fsmonitor b/t/t7065/no_untrackedcache_no_fsmonitor new file mode 100644 index 00000000000..e346deaa1db --- /dev/null +++ b/t/t7065/no_untrackedcache_no_fsmonitor @@ -0,0 +1,10 @@ +On branch test + +No commits yet + + +It took X seconds to enumerate untracked files. +See https://git-scm.com/docs/git-status#_untracked_files_and_status_speed +for configuration options that may improve that time. + +nothing to commit (create/copy files and use "git add" to track) diff --git a/t/t7065/with_untrackedcache_no_fsmonitor b/t/t7065/with_untrackedcache_no_fsmonitor new file mode 100644 index 00000000000..a649d367493 --- /dev/null +++ b/t/t7065/with_untrackedcache_no_fsmonitor @@ -0,0 +1,11 @@ +On branch test + +No commits yet + + +It took X seconds to enumerate untracked files, +but this is currently being cached, with fsmonitor OFF. +See https://git-scm.com/docs/git-status#_untracked_files_and_status_speed +for configuration options that may improve that time. + +nothing to commit (create/copy files and use "git add" to track) diff --git a/t/t7065/with_untrackedcache_with_fsmonitor b/t/t7065/with_untrackedcache_with_fsmonitor new file mode 100644 index 00000000000..d5e95d984f8 --- /dev/null +++ b/t/t7065/with_untrackedcache_with_fsmonitor @@ -0,0 +1,11 @@ +On branch test + +No commits yet + + +It took X seconds to enumerate untracked files, +but this is currently being cached, with fsmonitor ON. +See https://git-scm.com/docs/git-status#_untracked_files_and_status_speed +for configuration options that may improve that time. + +nothing to commit (create/copy files and use "git add" to track) diff --git a/wt-status.c b/wt-status.c index 5813174896c..be903c6e294 100644 --- a/wt-status.c +++ b/wt-status.c @@ -18,8 +18,10 @@ #include "worktree.h" #include "lockfile.h" #include "sequencer.h" +#include "fsmonitor-settings.h" #define AB_DELAY_WARNING_IN_MS (2 * 1000) +#define UF_DELAY_WARNING_IN_MS (2 * 1000) static const char cut_line[] = "------------------------ >8 ------------------------\n"; @@ -1205,6 +1207,17 @@ static void wt_longstatus_print_tracking(struct wt_status *s) strbuf_release(&sb); } +static inline int uf_was_slow(uint32_t untracked_in_ms) +{ + const char *x; + x = getenv("GIT_TEST_UF_DELAY_WARNING"); + if (x) { + untracked_in_ms += UF_DELAY_WARNING_IN_MS + 1; + } + + return UF_DELAY_WARNING_IN_MS < untracked_in_ms; +} + static void show_merge_in_progress(struct wt_status *s, const char *color) { @@ -1814,6 +1827,7 @@ static void wt_longstatus_print(struct wt_status *s) { const char *branch_color = color(WT_STATUS_ONBRANCH, s); const char *branch_status_color = color(WT_STATUS_HEADER, s); + enum fsmonitor_mode fsm_mode = fsm_settings__get_mode(s->repo); if (s->branch) { const char *on_what = _("On branch "); @@ -1870,13 +1884,25 @@ static void wt_longstatus_print(struct wt_status *s) wt_longstatus_print_other(s, &s->untracked, _("Untracked files"), "add"); if (s->show_ignored_mode) wt_longstatus_print_other(s, &s->ignored, _("Ignored files"), "add -f"); - if (advice_enabled(ADVICE_STATUS_U_OPTION) && 2000 < s->untracked_in_ms) { - status_printf_ln(s, GIT_COLOR_NORMAL, "%s", ""); - status_printf_ln(s, GIT_COLOR_NORMAL, - _("It took %.2f seconds to enumerate untracked files. 'status -uno'\n" - "may speed it up, but you have to be careful not to forget to add\n" - "new files yourself (see 'git help status')."), - s->untracked_in_ms / 1000.0); + if (uf_was_slow(s->untracked_in_ms)) { + if (advice_enabled(ADVICE_STATUS_U_OPTION)) { + status_printf_ln(s, GIT_COLOR_NORMAL, "%s", ""); + if (s->repo->settings.core_untracked_cache == UNTRACKED_CACHE_WRITE) { + status_printf_ln(s, GIT_COLOR_NORMAL, + _("It took %.2f seconds to enumerate untracked files,\n" + "but this is currently being cached, with fsmonitor %s."), + s->untracked_in_ms / 1000.0, + (fsm_mode > FSMONITOR_MODE_DISABLED) ? "ON" : "OFF"); + } else { + status_printf_ln(s, GIT_COLOR_NORMAL, + _("It took %.2f seconds to enumerate untracked files."), + s->untracked_in_ms / 1000.0); + } + status_printf_ln(s, GIT_COLOR_NORMAL, + _("See https://git-scm.com/docs/git-status#_untracked_files_and_status_speed\n" + "for configuration options that may improve that time.")); + status_printf_ln(s, GIT_COLOR_NORMAL, "%s", ""); + } } } else if (s->committable) status_printf_ln(s, GIT_COLOR_NORMAL, _("Untracked files not listed%s"),