From: <rsbecker@nexbridge.com>
To: "'Paul Jolly'" <paul@myitcv.io>, <git@vger.kernel.org>
Subject: RE: Automatically re-running commands during an interactive rebase or post commit
Date: Mon, 29 May 2023 09:41:08 -0400 [thread overview]
Message-ID: <002901d99233$3d0c8b80$b725a280$@nexbridge.com> (raw)
In-Reply-To: <CACoUkn7TmZ=trtDKcQm0SG5qCqK=-+YxrDV-7xYnLH_XK7K7og@mail.gmail.com>
>-----Original Message-----
On Monday, May 29, 2023 9:39 AM, Paul Jolly wrote:
>I would appreciate some advice on the best way to solve the following problem.
>
>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").
>
>As part of my development setup I do a lot of interactive rebasing to edit earlier
>commits in a branch (these "stacks" of changes are reviewed via Gerrit, which
>understands a relation chain of changes).
>Via this workflow, I often do a git rebase and edit an earlier commit in such a way
>that I need to re-run the code generation script.
>
>The challenge is that any commit in such a "stack" of commits might need me to re-
>run the code generation script. But I clearly don't want to do this manually!
>
>What I'm looking for is a way to automatically re-run this code generation script
>when I commit changes, or perform a rebase-edit step etc.
>
>I've tried to experiment with how I might do this using git commit hooks. But so far,
>my git foo is failing me. It mainly fails because when doing an edit of an earlier
>commit via an interactive rebase, later changes might well conflict (in the generated
>file) with the results of the code generator having been re-run on the edited commit.
>At this point, my git rebase --continue stops until I have fixed the conflict. But in
>almost all situations, the conflict comes in the generated hash file. Which I fix by
>simply re-running the code generation script (I could optionally fix it by doing a git
>checkout --theirs, and then re-running the code generation script).
>
>This all feels tantalisingly close to being a perfect workflow! But I can't quite figure
>out how to make the git hooks "work" in such a way that doesn't require any
>intervention from me (except in those situations where there is a conflict during the
>rebase that is _not_ in the code generated file and so does require my intervention).
>
>The code generation step is incredibly fast if there is nothing to do, and is quite fast
>even when there is something to do (in any case it can't avoid doing this work).
>
>Please can someone help nudge me in the right direction?
I wonder whether setting up a clean/smudge filter might help. You might want to look into a clean filter that runs your code generator.
--Randall
next prev parent reply other threads:[~2023-05-29 13:41 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 [this message]
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
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='002901d99233$3d0c8b80$b725a280$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--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).