Hello Junio,
On 2024-03-19 01:21, Junio C Hamano wrote:
Dragan Simic <dsimic@xxxxxxxxxxx> writes:
This patch series introduces new config option grep.includeUntracked,
which makes the untracked files also searched by default when
git-grep(1)
is invoked, in addition to searching the tracked files.
Hmph. I am moderately negative on any configuration that screws
with the default haystack from which needle is sought for.
I may often do "git grep --cached" but that does not mean I would
welcome an configuration option to make "git grep" search in the
index even when the request by the user does not have "--cached".
Inclusion of untracked sources in a sense is even worse, especially
when an unsuspecting "git grep" user (or a script) fully expects
that any paths found in the output are to be found in "git ls-files
-s" output but when you stray into a repository with the
configuration set, that expectation suddelnly gets broken.
Hmm... Those are valid concerns. For example, I'd also be against
another configuration option that would make it possible to enable
--cached by default, for example, because it could easily mess the
things up really bad.
However, I think that the usability of this new configuration option
outweighs the possible issues it could cause to some users. For
example, I quite often find myself in need to specify --untracked
while running git-grep(1), to see what's found in the code changes
I haven't staged yet, so I find this new configuration very useful.
Of course, I already have a few aliases defined for grep operations,
but defining another one for "grep --untracked" simply doesn't fit
into my alias scheme. Obviously, that's why I implemented this new
option, :) hoping that it would be usable to other people, too.
I'm not sure how many users could be affected by the possible negative
effects of this configuration option, by using a specific mix of git
operations, but I think it would be quite useful.
