Hi Elijah, On Tue, Jun 22, 2021 at 6:06 PM Elijah Newren <newren@xxxxxxxxx> wrote: > It may be that some combination of Kyle's removal of the > resolve_gitlink_ref() and my removal of the exponential traversal of > untracked paths make your idea safe...but this is dir.c and > untracked-cache, so who really knows? > > Not sure if that helps, but I hope one or two pointers I provided are > somehow meaningful to you. It is, thank you! I had already looked at those commits you mention, and my impression is indeed that any -uall incompatibilities have been addressed as a result of the major restructurings and fixes. After this exchange I prepared a patch that seems to be "right" from my perspective - it aligns the untracked cache flags with the config, so if your command-line "-uXXX" choice matches your config you get untracked cache, if it does not you get it disabled for that run (ie, in windows under some circumstances, surprisingly bad performance). This means people who want -uall to work well/performantly (because they prefer it, or because their tooling requires it) can now have it do so, simply by setting "git config status.showuntrackedfiles all". This seems much better than a new temporary config, it is not subject to "flip-flopping" issues like my previously described "naive" approach was, and it seems much more achievable than substantially changing the untracked cache structure & correspondingly adjusting the untracked directory iteration process to support both -unormal and -uall simultaneously within a single cache structure. The patch passes all (working) tests, including the t7603 untracked cache series I know you worked on, and seems to do exactly what I intend it to - but I'm new here, so there are probably many problems; hopefully this is interesting enough for people to take the time to point them out. The pull request in GitGitGadget is still requesting some form of approval before I can submit the patch to the mailing list: https://github.com/gitgitgadget/git/pull/985 Thanks, Tao
