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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.