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

[Dmitry Gutov]

On 26/01/2023 11:13, Mickey Petersen wrote:
> Dmitry Gutov <dgutov@yandex.ru> 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.