bug#74243: [PATCH] Speed up vc-hg-state by treating ignored files as unregistered

[Sean Whitton]

Hello,

On Thu 07 Nov 2024 at 12:41pm -05, Spencer Baugh via "Bug reports for GNU 
Emacs, the Swiss army knife of text editors" wrote:

> The most significant slow component of "hg status" is parsing the
> .hgignore file.  If we pass -mardc instead of -A to hg status, hg
> doesn't list ignored or untracked files, so it skips parsing the
> .hgignore.  On my large repo, this brings "hg status" from 140ms to
> 20ms.

Thanks for investigating this.

> For vc-hg-state, the distinction doesn't matter: nothing using the
> output of vc-hg-state has significantly different behavior for ignored
> files vs unregistered files:
> - vc-dir-clean-files and vc-dir-recompute-file-state call vc-hg-state,
>   but will never see an ignored file anyway since vc-dir shouldn't list
>   ignored files for hg.
> - vc-next-action checks 'ignored, but it's OK to take the
>   'unregistered path instead; it will either fail when calling hg, or
>   succeed.
> - Other users of vc-state don't differ between 'ignored and
>   'unregistered

In vc-dir for a git repo, if I type 'G' on an unregistered file and then
'g' to refresh the view, the status label next to the unregistered file
changes to "ignored".  ISTM this is a nice feature that allows you to
confirm that the addition to .gitignore worked.

If that doesn't currently work for Hg, someone might want to implement
it at some point.  vc-state is a public function, so someone might well
be relying on it returning 'ignored, for some other purpose.

So, can we do this with a new optional argument to vc-state?  Like how
vc-deduce-fileset can provide more information if STATE-MODEL-ONLY-FILES
is non-nil.  It could be an optional argument that means to treat
'ignored and 'unregistered the same.  Or something similar.

It seems well-motivated to add an argument to the general vc-status
because it's an operation that can be slow in large repos regardless of
the backend.  Though we could start by just adding an optional argument
to vc-hg-status.

Or, less invasive would be a vc-hg--status-internal which does it.

-- 
Sean Whitton