From: Dmitry Gutov <dgutov@yandex.ru>
To: Mickey Petersen <mickey@masteringemacs.org>
Cc: 61038@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 17:50:29 +0200 [thread overview]
Message-ID: <40efee33-4142-90ac-b7b4-7ea19dd688ee@yandex.ru> (raw)
In-Reply-To: <877cx9bqd8.fsf@masteringemacs.org>
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.
prev parent reply other threads:[~2023-01-26 15:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-24 10:37 bug#61038: 30.0.50; `project-query-replace-regexp' also attempts search and replace in auto-save files Mickey Petersen
2023-01-24 23:20 ` Dmitry Gutov
2023-01-25 7:30 ` Mickey Petersen
2023-01-25 15:29 ` Dmitry Gutov
2023-01-25 20:34 ` Mickey Petersen
2023-01-25 23:43 ` Dmitry Gutov
2023-01-26 9:13 ` Mickey Petersen
2023-01-26 15:50 ` Dmitry Gutov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40efee33-4142-90ac-b7b4-7ea19dd688ee@yandex.ru \
--to=dgutov@yandex.ru \
--cc=61038@debbugs.gnu.org \
--cc=mickey@masteringemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).