2005-07-09 01:51:55 +02:00
|
|
|
git-hash-object(1)
|
|
|
|
|
==================
|
|
|
|
|
|
|
|
|
|
NAME
|
|
|
|
|
----
|
2007-01-19 00:53:37 +01:00
|
|
|
git-hash-object - Compute object ID and optionally creates a blob from a file
|
2005-07-09 01:51:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
|
--------
|
2008-08-03 16:36:19 +02:00
|
|
|
[verse]
|
2022-10-13 17:39:06 +02:00
|
|
|
'git hash-object' [-t <type>] [-w] [--path=<file> | --no-filters]
|
2022-10-13 17:39:02 +02:00
|
|
|
[--stdin [--literally]] [--] <file>...
|
usage: do not insist that standard input must come from a file
The synopsys text and the usage string of subcommands that read list
of things from the standard input are often shown like this:
git gostak [--distim] < <list-of-doshes>
This is problematic in a number of ways:
* The way to use these commands is more often to feed them the
output from another command, not feed them from a file.
* Manual pages outside Git, commands that operate on the data read
from the standard input, e.g "sort", "grep", "sed", etc., are not
described with such a "< redirection-from-file" in their synopsys
text. Our doing so introduces inconsistency.
* We do not insist on where the output should go, by saying
git gostak [--distim] < <list-of-doshes> > <output>
* As it is our convention to enclose placeholders inside <braket>,
the redirection operator followed by a placeholder filename
becomes very hard to read, both in the documentation and in the
help text.
Let's clean them all up, after making sure that the documentation
clearly describes the modes that take information from the standard
input and what kind of things are expected on the input.
[jc: stole example for fmt-merge-msg from Jonathan]
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16 20:27:42 +02:00
|
|
|
'git hash-object' [-t <type>] [-w] --stdin-paths [--no-filters]
|
2005-07-09 01:51:55 +02:00
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
|
-----------
|
|
|
|
|
Computes the object ID value for an object with specified type
|
|
|
|
|
with the contents of the named file (which can be outside of the
|
|
|
|
|
work tree), and optionally writes the resulting object into the
|
|
|
|
|
object database. Reports its object ID to its standard output.
|
2019-05-20 23:53:10 +02:00
|
|
|
When <type> is not specified, it defaults to "blob".
|
2005-07-09 01:51:55 +02:00
|
|
|
|
2005-08-05 17:05:02 +02:00
|
|
|
OPTIONS
|
|
|
|
|
-------
|
|
|
|
|
|
|
|
|
|
-t <type>::
|
|
|
|
|
Specify the type (default: "blob").
|
|
|
|
|
|
|
|
|
|
-w::
|
|
|
|
|
Actually write the object into the object database.
|
2005-07-09 01:51:55 +02:00
|
|
|
|
2005-12-10 23:25:24 +01:00
|
|
|
--stdin::
|
|
|
|
|
Read the object from standard input instead of from a file.
|
|
|
|
|
|
2008-05-23 16:19:38 +02:00
|
|
|
--stdin-paths::
|
usage: do not insist that standard input must come from a file
The synopsys text and the usage string of subcommands that read list
of things from the standard input are often shown like this:
git gostak [--distim] < <list-of-doshes>
This is problematic in a number of ways:
* The way to use these commands is more often to feed them the
output from another command, not feed them from a file.
* Manual pages outside Git, commands that operate on the data read
from the standard input, e.g "sort", "grep", "sed", etc., are not
described with such a "< redirection-from-file" in their synopsys
text. Our doing so introduces inconsistency.
* We do not insist on where the output should go, by saying
git gostak [--distim] < <list-of-doshes> > <output>
* As it is our convention to enclose placeholders inside <braket>,
the redirection operator followed by a placeholder filename
becomes very hard to read, both in the documentation and in the
help text.
Let's clean them all up, after making sure that the documentation
clearly describes the modes that take information from the standard
input and what kind of things are expected on the input.
[jc: stole example for fmt-merge-msg from Jonathan]
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16 20:27:42 +02:00
|
|
|
Read file names from the standard input, one per line, instead
|
|
|
|
|
of from the command-line.
|
2008-05-23 16:19:38 +02:00
|
|
|
|
2008-08-03 16:36:21 +02:00
|
|
|
--path::
|
|
|
|
|
Hash object as it were located at the given path. The location of
|
|
|
|
|
file does not directly influence on the hash value, but path is
|
2013-01-21 20:17:53 +01:00
|
|
|
used to determine what Git filters should be applied to the object
|
2008-08-03 16:36:21 +02:00
|
|
|
before it can be placed to the object database, and, as result of
|
|
|
|
|
applying filters, the actual blob put into the object database may
|
|
|
|
|
differ from the given file. This option is mainly useful for hashing
|
|
|
|
|
temporary files located outside of the working directory or files
|
|
|
|
|
read from stdin.
|
|
|
|
|
|
2008-08-03 16:36:22 +02:00
|
|
|
--no-filters::
|
|
|
|
|
Hash the contents as is, ignoring any input filter that would
|
2010-07-19 23:17:17 +02:00
|
|
|
have been chosen by the attributes mechanism, including the end-of-line
|
2008-08-03 16:36:22 +02:00
|
|
|
conversion. If the file is read from standard input then this
|
2015-05-04 09:25:13 +02:00
|
|
|
is always implied, unless the `--path` option is given.
|
|
|
|
|
|
|
|
|
|
--literally::
|
|
|
|
|
Allow `--stdin` to hash any garbage into a loose object which might not
|
|
|
|
|
otherwise pass standard object parsing or git-fsck checks. Useful for
|
|
|
|
|
stress-testing Git itself or reproducing characteristics of corrupt or
|
|
|
|
|
bogus objects encountered in the wild.
|
2008-08-03 16:36:22 +02:00
|
|
|
|
2005-07-09 01:51:55 +02:00
|
|
|
GIT
|
|
|
|
|
---
|
2008-06-06 09:07:32 +02:00
|
|
|
Part of the linkgit:git[1] suite
|