Re: [PATCH 3/3] grep docs: describe --no-index further and improve formatting a bit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Jean-Noël,

On 2024-03-23 20:26, Jean-Noël AVILA wrote:
On Wednesday, 20 March 2024 22:08:46 CET Dragan Simic wrote:
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index f64f40e9775a..b144401b3698 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -28,7 +28,7 @@ SYNOPSIS
 	   [-f <file>] [-e] <pattern>
 	   [--and|--or|--not|(|)|-e <pattern>...]
 	   [--recurse-submodules] [--parent-basename <basename>]
-	   [ [--[no-]exclude-standard] [--cached | --no-index | --
untracked] | <tree>...]
+	   [ [--[no-]exclude-standard] [--cached | --untracked | --no-
index] | <tree>...]

This change gives precedence to some option in alternatives, which seems
weird.

As explained in the patch description, it isn't about the precedence,
but about grouping together the options that have something in common.
In more detail, --cached and --untracked have something in common,
i.e. they both leave git-grep in the usual state, in which it treats
the directory as a local git repository, unlike --no-index that makes
git-grep treat the directory not as a git repository.

@@ -45,13 +45,20 @@ OPTIONS
 	Instead of searching tracked files in the working tree, search
 	blobs registered in the index file.

---no-index::
-	Search files in the current directory that is not managed by Git.
-
 --untracked::
 	In addition to searching in the tracked files in the working
 	tree, search also in untracked files.

+--no-index::
+	Search files in the current directory that is not managed by Git,
+	or by ignoring that the current directory is managed by Git.  This
+	allows `git-grep(1)` to be used as the regular `grep(1)` utility,

Auto-referencing the git-grep manpage in itself is useless.

Please note this isn't a link, it just mentions the operation.  Though,
I agree that rewording it a bit might be beneficial.

When grepping the object store (with `--cached` or giving tree objects),
running
-with multiple threads might perform slower than single threaded if `--
textconv`
-is given and there are too many text conversions. So if you experience low
-performance in this case, it might be desirable to use `--threads=1`.
+with multiple threads might perform slower than single-threaded if `--
textconv`
+is given and there are too many text conversions. Thus, if low performance
is
+experienced in this case, it might be desirable to use `--threads=1`.

I'm not native speaker, but I'm not sure the switch to passive form is
helpful. In Simplified English, passive form is considered harmful and
difficult to translate because the subject is elided.

In general, not addressing the user/reader directly is preferred in
technical documentation, because it eliminates the possible element
of persuading the user to do something.  In other words, we should be
telling the user what our software can do, instead of telling the
user what to do.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux