On Mon, May 29, 2023 at 02:38:40PM +0100, Paul Jolly wrote:
As part of my project, I have a code generation script that sha256
hashes a number of files to another file. This produces a
deterministic "has this part of the project changed" indicator via the
code generated file's content, that I then use in various cache
invalidation steps.
This means, however, that I need to re-run that code generation script
as part of each commit in order to ensure that the code generated hash
file is current (I have a step in CI that detects if it is not, which
re-runs the code generation script to then see if the commit is
"clean").
i would recommend taking a step back and considering whether you're
actually trying to fix the right problem.
why are you checking in an auto-generated file, esp. given that it can
be generated very quickly as you report?
usually, this should be done by the build system.
if the used build tool really is too dumb to integrate it into the build
system, you might have luck with a post-checkout hook.
you can also obtain existing hashes directly from git, with ls-tree,
though this would again require some kind of integration with the build
or checkout process.
if you can't get around checking in the hash, i can think of hacking it
using rebase --exec. basically, before each pick you'd create a commit
that reverts the hash change (by checking out that path from the parent
of the last commit that touched it, found automatically with git log),
and after the pick you'd squash away the revert (using `reset HEAD~2 &&
commit -C @{1}` or something to that effect). very ugly, very fragile.
regards,
ossi
