Re: Automatically re-running commands during an interactive rebase or post commit

From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date: May 30, 2023, 09:44 UTC
Message-ID: <ZHXFdRnrwzNCA227@ugly>
In-Reply-To: <CACoUkn7TmZ=trtDKcQm0SG5qCqK=-+YxrDV-7xYnLH_XK7K7og@mail.gmail.com>

On Mon, May 29, 2023 at 02:38:40PM +0100, Paul Jolly wrote:

Show 12 quoted lines

>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