c头文件递归git log漂亮格式

Question

I am trying to combine git version information into one c header file.

try this script

#!/bin/bash
curr_path=$(pwd)
submodule_path_array=($(git submodule foreach "git submodule foreach pwd && pwd" | grep "${curr_path}*"))

echo "#ifndef __GITVER_H__" > ${curr_path}/gitver.h
echo "#define __GITVER_H__" >> ${curr_path}/gitver.h

for path in ${submodule_path_array[@]}
do
    cd ${path}
    txt_format="'#define COMMIT_$(basename "$path") \"%H\"%n'"
    echo -e ${txt_format}
    git log --pretty=tformat:${txt_format} -n 1 >> ${curr_path}/gitver.h
done

echo "#endif" >> ${curr_path}/gitver.h

cd ${curr_path}

but the output is as follows

$ ./git_ver.sh
'#define COMMIT_submodule0 "%H"%n'
fatal: ambiguous argument 'COMMIT_submodule0': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
'#define COMMIT_submodule1 "%H"%n'
fatal: ambiguous argument 'COMMIT_submodule1': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
'#define COMMIT_submodule2 "%H"%n'
fatal: ambiguous argument 'COMMIT_submodule2': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

What would you like to do?

Answer 1

The immediate cause of the error is here, as Renaud Pacalet noted in a comment :

 git log --pretty=tformat:${txt_format} -n 1 >> ${curr_path}/gitver.h

The txt_format variable is set, a few lines earlier, to a string that includes spaces. When bash (or any POSIX shell) interpolates the string into ${txt_format} , these spaces cause word-breaking, so that you're running:

git log --pretty=tformat:'#define COMMIT_submodule0 "%H"%n' -n 1

What you had intended to run is:

git log --pretty=tformat:#define COMMIT_submodule0 "%H"%n -n 1

which requires using double quotes around the expansion of $txt_format (and, as the same comment notes, removing the single quotes from the setting). Note that any quotes—single or double—embedded in the text expansion do not affect the word-breaking of the expansion; the word-breaking is determined solely by whether the expansion itself is quoted. (In effect, the quotes are "painted over" during the expansion so that they cannot affect the result: they don't look like quotes any more. ¹ The variable is expanded, words get broken up, and then only towards the end is the "paint" removed from the quotes so that git will see them as quote characters.)

It is, however, worth noting something else about submodules that eliminates the need to put in one hash per submodule, and that is this: By design, the commit hash ID in the superproject completely determines all the commit hash IDs in each submodule. After cloning the superproject, you git checkout or git switch -to the selected commit hash ID in the superproject. Then you run git submodule update --init (with --recursive if needed), and the commit that you selected in the superproject has, in each of its gitlink entries that controls each submodule, the raw hash ID of that submodule.

It's possible to violate this design assumption (in which case you would in fact need every submodule hash ID), but you should never do it for any official build. So storing the hash ID of the superproject alone should normally suffice.

It's also worth mentioning a few other items:

• To get the full raw hash ID of the current commit, simply run git rev-parse HEAD . There's no need to run git log --format=%H -n 1 . (Of course if you want some additional decoration, you'll need to add that, and git log 's formatting directives are one way to add it, so at this point it becomes kind of six-of-one half-a-dozen-of-the-other.)

• The git describe command is the usual way most people choose to produce a "human-oriented" hash ID for version consumption. Just how human-oriented this is (or could possibly be) is a bit of an open question, but when building a release from a release tag, this gives you a very nice v2.10 or whatever.

So, usually we just want:

printf "#ifndef VERSION\n#define VERSION \"%s\"\n#endif\n" \
    $(git describe --tags --always --dirty) > version.h

or similar as our "version generator".

---

¹ In ancient (non-8-bit-clean) versions of /bin/sh this "painting over" was done by setting the high bit of every character, so that quotes and glob characters were no longer ' or * or whatever. Then the 0x80 bit was removed just before the execve system call. Since shells now have to allow all these byte values to pass through, this trick is no longer possible, but it still describes the behavior: you just have to imagine something other than c | 0x80 c | 0x80 happening. For instance, the shell could store the bytes in short variables and use c | 0x100 c | 0x100 , and then use c & 0xff to strip off the "paint".)