From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
To: Paul Jolly <paul@myitcv.io>
Cc: git@vger.kernel.org
Subject: Re: Automatically re-running commands during an interactive rebase or post commit
Date: Tue, 30 May 2023 11:44:21 +0200 [thread overview]
Message-ID: <ZHXFdRnrwzNCA227@ugly> (raw)
In-Reply-To: <CACoUkn7TmZ=trtDKcQm0SG5qCqK=-+YxrDV-7xYnLH_XK7K7og@mail.gmail.com>
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
next prev parent reply other threads:[~2023-05-30 9:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-29 13:38 Automatically re-running commands during an interactive rebase or post commit Paul Jolly
2023-05-29 13:41 ` rsbecker
2023-05-29 14:01 ` Paul Jolly
2023-05-29 16:02 ` Paul Jolly
2023-05-29 17:53 ` Phillip Wood
2023-05-29 19:08 ` Paul Jolly
2023-05-29 19:48 ` Phillip Wood
2023-05-31 4:14 ` Elijah Newren
2023-06-02 9:57 ` Phillip Wood
2023-06-08 5:11 ` Paul Jolly
2023-05-30 7:22 ` Son Luong Ngoc
2023-05-30 9:44 ` Oswald Buddenhagen [this message]
2023-05-30 10:27 ` Paul Jolly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZHXFdRnrwzNCA227@ugly \
--to=oswald.buddenhagen@gmx.de \
--cc=git@vger.kernel.org \
--cc=paul@myitcv.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).