Thread (7 messages) 7 messages, 4 authors, 2022-03-30

Re: [Question] .git folder file updates for changing head commit

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2022-03-27 15:57:54

On Wed, Mar 23 2022, Taylor Blau wrote:
On Wed, Mar 23, 2022 at 03:19:06PM +0000, John Garry wrote:
quoted
For building the linux perf tool we use the git head commit id as part of
the tool version sting. To save time in re-building, the Makefile rule has a
dependency on .git/HEAD for rebuilding. An alternative approach would be to
compare git log output to check current versus previous build head commit,
but that is seen as inefficient time-wise.
Having a Makefile recipe that depends on $GIT_DIR/HEAD seems strange to
me.

Presumably your Makefile rules would map out which parts of your program
depend on each other, and would get invalidated when the source itself
changes, no?

Perhaps you also care about the commit you're building from in order to
embed something into your program. But it seems like you could inject
the output of "git rev-parse HEAD" when you construct the version
identifier whenever you do need to rebuild.
Our very own build process for git.git relies on this, see how version.o
needs a GIT-VERSION-FILE, which we generate by shelling out and
including.

It is unfortunate that we don't have an advertised way to do this, with
the ref backend I think trickery using $(file) to read the HEAD will
work to do it in pure-make, i.e. you'd need to parse it to see if it's a
symref, then depend on the target it points to.

Or you could recursively depend on a glob of the whole refspace for
generating the version file ...

It would be nice if we had a way to guarantee that we'd write some file
on HEAD updates, AFAIK not even the new reference-transaction hook will
do that (due to "git reset --hard" and friends).

And yes, this does actually matter. There's a huge performance
difference between a Makefile that needs to shell out for every little
thing.

I've been optimizing our own Makefile incrementally from running in
~500ms down to 100-200ms for noop runs over over the last few
months. It's possible to get it down to 10-20ms at least by getting rid
of the remaining shell-outs.

That makes a big difference when e.g. using "make" with "git rebase -i
-x".
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help