GIT-HASH-OBJECT(1)

πŸ’… GIT-HASH-OBJECT(1) πŸ’…

okay so this is the manual page for git-hash-object, bestie β€” it's living in the GIT-HASH-OBJECT(1) slot of your man pages and it's gonna teach you how to compute an object ID and, if you want, actually make an object out of a file. pull up a chair πŸŽ€


✨ NAME ✨

git-hash-object β€” compute object ID and optionally create an object from a file


🌸 SYNOPSIS 🌸

git hash-object [-t <type>] [-w] [--path=<file> | --no-filters]
                [--stdin [--literally]] [--] <file>...
git hash-object [-t <type>] [-w] --stdin-paths [--no-filters]

πŸ¦‹ DESCRIPTION πŸ¦‹

So what does this little icon actually do? It computes the object ID value for an object of a specified type, using the contents of the named file β€” and yes, that file can totally be chillin' outside of the work tree, no big deal. It can also optionally write the resulting object into the object database for you, which is the "make it real" option 😌

Then it reports its object ID to its standard output. That's the whole vibe β€” you get the hash, you go about your day.

Oh, and when <type> isn't specified? It defaults to "blob". periodt.


πŸ’– OPTIONS πŸ’–

  • -t <type> β€” specify the type of object to be created (default: "blob"). the possible values are commit, tree, blob, and tag. pick your fighter 🫢
  • -w β€” actually write the object into the object database. like, for real for real. no -w, no write, simple as that.
  • --stdin β€” read the object from standard input instead of from a file. feeding it through the pipe, main character energy πŸ”₯
  • --stdin-paths β€” read file names from the standard input, one per line, instead of from the command-line. very "here's my list, don't @ me" of you.
  • --path β€” hash object as if it were located at the given path. the location of the file does not directly influence the hash value, but the path is used to determine which Git filters should be applied to the object before it can be placed in the object database. and here's the plot twist: as a 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.
  • --no-filters β€” hash the contents as is, ignoring any input filter that would have been chosen by the attributes mechanism, including the end-of-line conversion. and heads up: if the file is read from standard input then this is always implied, unless the --path option is given. so don't come for it, it's just how it is πŸ’…
  • --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. yes literally any garbage. chaos permitted, but read that again β€” it's for stress-testing Git and reproducing corrupt/bogus objects, not for your everyday hashing πŸ’€

πŸ‘‘ GIT πŸ‘‘

Part of the git(1) suite. you already knew that though, iykyk 🌈


and that's the whole page, bestie β€” go forth and hash ✨

this was brought to you by Git 2.56.0, dated 2026-09-27. love that for us. πŸ’œπŸ¦‹πŸŽ€

πŸ“¦ where this page comes from