Git modify contents of index directly for pre-commit formatting hook

Question

I would like to automatically format my files before they are added to Git's index. Right now, I have a pre-commit hook that looks like this:

#!/bin/bash

set -e
exec 1>&2

workingext="working.$$"
ext="bak.$$"
git diff -z --cached --name-only | egrep -z '\.(pl|pm|t)$' | \
        while read -d'' -r f; do
    # First modify the file in the index
    mv "$f" "$f.$workingext"
    git show :"$f" > "$f"
    perl -c "$f"
    perltidy -pbp -nst -b -bext="$ext" "$f";
    rm -f "$f.$ext"
    git add "$f"
    mv "$f.$workingext" "$f"
    # Then the working copy
    perl -c "$f"
    perltidy -pbp -nst -b -bext="$ext" "$f";
    rm -f "$f.$ext"
done

Basically, I back up the working copies, check out the indexed copies, format them, add them to the index, and then restore the working copies and format them too, so that the differences between the working and indexed copies don't grow too large. I check the syntax of the files using perl -c first so that the formatter perltidy can't get too confused by a syntactically invalid file.

So far, this seems to be working pretty well. However, I'd like to know if there's a way to add the contents of one file to the index under the name of another file. That is, a command like git update-index-from-file --from-file foo.pl.tmp foo.pl would update the file foo.pl such that its contents in the index came entirely from foo.pl.tmp, but whose version in the working directory remained unmodified. This might avoid the dance of renamings I'm doing right now (although that might be useful to ensure I don't lose the contents of the index irretrievably).

Mopup

Answer 1

Yes, that’s possible. First, you need to create a blob from your file by running this command:

git hash-object -w foo.pl.tmp

See here: http://www.kernel.org/pub/software/scm/git/docs/git-hash-object.html

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.

Using the blob sha that git hash-object sent to STDOUT, you can now add this blob as “foo.pl” to your index by running

git update-index --add --cacheinfo 100644 *YOURSHA* foo.pl

From the manpage of update-index:

--cacheinfo is used to register a file that is not in the current working directory. This is useful for minimum-checkout merging.

To pretend you have a file with mode and sha1 at path, say:

$ git update-index --cacheinfo mode sha1 path

But I’d like to note that your situation looks a lot like you should actually use a smudge filter to do that stuff. See here to learn about them: https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Keyword-Expansion

Larsen

Great answer. Allowed me to clean up my solution to a similar (same?) problem (I gave the credit :D). Now it became basically a coded version of this one. – Gadfly

The problem with a clean and smudge filter is that, unlike the precommit hook, it isn't stored. Each use has their own git config so each user that checks out the code will need to reconfigure the filter. – Pernod

From what I can tell --add is needed when you want to add a not yet versioned file. And --cacheinfo is needed to make use of the blob you created with git hash-object. Otherwise (git update-index PATH) it'll take your path and create its own blob. – Flofloat