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 <ava...@gmail.com> --- 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
