Subject: [PATCH 3/3] hash-object doc: point to ls-files and rev-parse

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Mon, 20 May 2019 23:53:12 +0200

Amend the intro to note that it's better to ask the index about files
already tracked by it.

I've seen uses of this in the wild where the use-case was finding
object IDs for files found in a freshly cloned repo, i.e. something
like "git ls-files | git hash-object --stdin-paths".

Signed-off-by: Ævar Arnfjörð Bjarmason <[email-masked]>
---
 Documentation/git-hash-object.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt
index 100630d021..077d83ec65 100644
--- a/Documentation/git-hash-object.txt
+++ b/Documentation/git-hash-object.txt
@@ -20,6 +20,13 @@ work tree), and optionally writes the resulting object into the
 object database.  Reports its object ID to its standard output.
 When <type> is not specified, it defaults to "blob".
 
+This command won't take the shortcut of seeing if the path(s) to be
+hashed are present in the index, in which case their already computed
+object ID could be retrieved by linkgit:git-ls-files[1] via the
+`--stage` option, or by linkgit:git-rev-parse[1]. Use those instead of
+e.g. `--stdin-paths` if the intent is to say find the blob object IDs
+of checked-out files.
+
 OPTIONS
 -------
 
-- 
2.21.0.1020.gf2820cf01a