Subject: bug#61038: 30.0.50; `project-query-replace-regexp' also attempts search and replace in auto-save files

From: Dmitry Gutov <[email-masked]>
Date: Thu, 26 Jan 2023 17:50:29 +0200

On 26/01/2023 11:13, Mickey Petersen wrote:
> 
> Dmitry Gutov <[email-masked]> writes:
> 
>> On 25/01/2023 22:34, Mickey Petersen wrote:
>>
>>> (Actually this issue also afflicts auto-save files in my Emacs.)
>>> And the files in question are not committed to the index, nor are
>>> they
>>> part of the git tree. So they're just stray files that happen to be
>>> important (backup, auto save) to Emacs.
>>> It seems odd that you'd want to search and replace those by default,
>>> particularly when Emacs is well aware of the fact that they are indeed
>>> backups or auto saves of other files used by that instance of Emacs.
>>
>> I'm asking why they are not in your .gitignore already. They must get
>> in the way of operations such as 'git status', or 'git add *', or 'git
>> commit -a', or just in the way of shell completion for 'git add ...'.
>>
> 
> Let's assume I'm simplifying a more complex workflow to aid with the
> bug report.

Okay.

> There are many legitimate reasons for having binary files -- large
> ones too -- in a repository. Though it's uncommon with git, as it does
> a poor job handling them.
> 
> There are also legitimate reasons for not having expansive ignore
> files, particularly with version control systems that lack the
> granularity of Git and its ilk.
> 
> Nevertheless, knowing that untracked are also considered part of the
> project, I can now set `project-vc-include-untracked' to nil to at
> least resolve this. It would seem I was not the only one who chafed at
> this edge case.

You can also customize project-vc-ignores to fine-tune which additional 
file to skip specifically (whether tracked or not).

But if "skip untracked" suits your mental model well, even better (it 
also increases file listing's performance).

As a default behavior, though, I think it's problematic because one 
might work for a significant amount of time on a bunch of new files 
before committing them. Depends on a workflow.

>>> So, yes, `grep-find-ignored-files' (or a project.el equivalent) should
>>> indeed exist.
>>
>> grep-find-ignored-files is a real user option already. You can also
>> use project-vc-ignores, but it's nil by default.
>>
>> A couple of reasons not to use grep-find-ignored-files patterns by default:
>>
>> - Some users might be actually looking for one of those files, and
>>    would get surprised that while the Git repository lists them fine
>>    (perhaps they even checked in such file; maybe they're using unusual
>>    file naming schemes), but our project backend does not.
>>
>> - Every addition to the ignored patterns is a minor but steady
>>    performance hit. grep-find-ignored-files has 61 element by
>>    default. Dropping all of those into project--vc-list-files can
>>    create a performance hit of an order of a magnitude. E.g. in my
>>    testing the time to list the files in gecko-dev went up from 1s to
>>   about 5s.
> 
> Sure. But `git-grep(1)' will ignore binary files by default, for example.

Hmm, I think in our case the step which will ignore the binary files is 
the search program. So (project-files) will include them in the listing, 
but both Grep and Ripgrep will skip them during the search.