unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.






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