There's rarely a good reason to do this, but the parameter is
--allow-empty for empty commits, in contrast to
--allow-empty-message for empty messages. You can also read more by typing
git help commit or visiting the online documentation.
While the tree object (which has a hash of its own) will be identical, the commit will actually have a different hash, because it will presumably have a different timestamp and message, and will definitely have a different parent commit. All three of those factors are integrated into
git's object hash algorithm.
There are a few reasons you might want an empty commit (incorporating some of the comments):
- As a "declarative commit", to add narration or documentation (via DavidNeiss) including after-the-fact data about passing tests or lint (via Robert Balicki).
- To test
git commands without generating arbitrary changes (via Vaelus).
- To re-create a deleted bare repository using
gitolite (via Tatsh).
- To arbitrarily create a new commit, such as for re-triggering build tooling (via mattLummus) or for the sake of personal logging or metrics (via BlueJ774). However, think twice: depending on your branch/merge structure, commits may live for a very long time, so a "just commit nothing" strategy may be inadvertently pollute your team's repository with temporary workflow artifacts and make it hard to separate code revisions from ephemeral cruft.
Other strategies to add metadata to a commit tree include:
- Separate branches or lightweight tags that always point to a commit of a particular status (e.g. "last accepted commit" or "current staging commit").
- Annotated Tags for a way to record timestamp, committer, and message, pointing to an existing commit without adding an entry in the commit tree itself.
git notes to associate a mutable note on top of an existing immutable commit.