In Git, how can I write the current commit hash to a file in the same commit

It's impossible to write the current commit hash: if you manage to pre-calculate the future commit hash — it will change as soon as you modify any file.

However, there're three options:

1. Use a script to increment 'commit id' and include it somewhere. Ugly
2. .gitignore the file you're going to store the hash into. Not very handy
3. In pre-commit, store the previous commit hash :) You don't modify/insert commits in 99.99% cases, so, this WILL work. In the worst case you still can identify the source revision.

I'm working on a hook script, will post it here 'when it's done', but still — earlier than Duke Nukem Forever is released :))

Update: code for .git/hooks/pre-commit:

#!/usr/bin/env bash
set -e

#=== 'prev-commit' solution by o_O Tync
#commit_hash=$(git rev-parse --verify HEAD)
commit=$(git log -1 --pretty="%H%n%ci") # hash \n date
commit_hash=$(echo "$commit" | head -1)
commit_date=$(echo "$commit" | head -2 | tail -1) # 2010-12-28 05:16:23 +0300

branch_name=$(git symbolic-ref -q HEAD) # http://stackoverflow.com/questions/1593051/#1593487
branch_name=${branch_name##refs/heads/}
branch_name=${branch_name:-HEAD} # 'HEAD' indicates detached HEAD situation

# Write it
echo -e "prev_commit='$commit_hash'\ndate='$commit_date'\nbranch='$branch'\n" > gitcommit.py

Now the only thing we need is a tool that converts prev_commit,branch pair to a real commit hash :)

I don't know whether this approach can tell merging commits apart. Will check it out soon

This can be achieved by using the filter attribute in gitattributes. You'd need to provide a smudge command that inserts the commit id, and a clean command that removes it, such that the file it's inserted in wouldn't change just because of the commit id.

Thus, the commit id is never stored in the blob of the file; it's just expanded in your working copy. (Actually inserting the commit id into the blob would become an infinitely recursive task. ☺) Anyone who clones this tree would need to set up the attributes for herself.

Someone pointed me to "man gitattributes" section on ident, which has this:

ident

When the attribute ident is set for a path, git replaces $Id$ in the blob object with $Id:, followed by the 40-character hexadecimal blob object name, followed by a dollar sign $ upon checkout. Any byte sequence that begins with $Id: and ends with $ in the worktree file is replaced with $Id$ upon check-in.

If you think about it, this is what CVS, Subversion, etc do as well. If you look at the repository, you'll see that the file in the repository always contains, for example, $Id$. It never contains the expansion of that. It's only on checkout that the text is expanded.

Think outside of the commit box!

pop this into the file hooks/post-checkout

#!/bin/sh
git describe --all --long > config/git-commit-version.txt

The version will be available everywhere you use it.

I don't think you actually want to do that, because when a file in the commit is changed, the hash of the commit is also changed.

Let me explore why this is a challenging problem using the git internals. You can get the sha1 of the current commit by

#!/bin/bash
commit=$(git cat-file commit HEAD) #
sha1=($((printf "commit %s\0" $(echo "$commit" | wc -c); echo "$commit") | sha1sum))
echo ${sha1[0]}

Essentially you run a sha1 checksum on the message returned by git cat-file commit HEAD. Two things immediately jump out as a problem when you examine this message. One is the tree sha1 and the second is the commit time.

Now the commit time is easily taken care of by altering the message and guessing how long it takes to make a commit or scheduling to commit at a specific time. The true issue is the tree sha1, which you can get from git ls-tree $(git write-tree) | git mktree. Essentially you are doing a sha1 checksum on the message from ls-tree, which is a list of all the files and their sha1 checksum.

Therefore your commit sha1 checksum depends on your tree sha1 checksum, which directly depends on the files sha1 checksum, which completes the circle and depends on the commit sha1. Thus you have a circular problem with techniques available to myself.

With less secure checksums, it has been shown possible to write the checksum of the file into the file itself through brute force; however, I do not know of any work that accomplished that task with sha1. This is not impossible, but next to impossible with our current understanding (but who knows maybe in a couple years it will be trivial). However, still this is even harder to brute force since you have to write the (commit) checksum of a (tree) checksum of a (blob) checksum into the file.

I prefer simply writing the exact date-time and the parent commit's hash, so in hooks/pre-commit I write the below code:

#!/bin/bash
ver_file=version.txt
> $ver_file
date +"%Y-%m-%d %T %:z" >> $ver_file
echo -n "Parent: " >> $ver_file
git rev-parse HEAD >> $ver_file
git add $ver_file
echo "Date-time and parent commit added to '$ver_file'"
exit 0

Sample auto-generated version.txt file:

2023-05-24 01:24:12 +03:30
Parent: 35acd10240a55d164b371aa28812e8e988ab0c8d

This method also keeps working when you checkout to another commit, as the version.txt file is stored exactly the way the other files are stored, and also in remote repositories and submodules for the same reason, but you have to make sure that the same file exists in .git/hooks/pre-commit for your submodule or remote repository as well.

Downsides

1. It's not supported on GitHub and perhaps some other websites.

2. There will always be a conflict on version.txt when performing merge, however, no further actions other than a commit -am <message> is needed since pre-commit will also be run before doing the merge's commit.