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

Previous Next

Full log

View this message in rfc822 format

From: Mickey Petersen <mickey <at> masteringemacs.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61038 <at> debbugs.gnu.org
Subject: bug#61038: 30.0.50; `project-query-replace-regexp' also attempts search and replace in auto-save files
Date: Thu, 26 Jan 2023 09:13:31 +0000

Dmitry Gutov <dgutov <at> 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.

>> And yes indeed: why not make the project replace mechanism ignore dumb
>> things no one wants to edit.
>
> The "project replace mechanism" uses the same set of files that you
> get in completion for project-find-file. Or search through with
> 'project-find-regex'.
>
> So far the semantics of the vc-aware backend has been that all files
> that Git doesn't consider ignored (tracked or untracked) are
> considered to be part of the project.
>
>> And committing large, binary files to a tree is common in a wide range
>> of situations, though less so in Git, as it's terrible at it.
>
> That's why people usually put the binary files, backup files, etc, in
> .gitignore.
>

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.

>> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.