From: Paul Jolly <paul@myitcv.io>
To: git@vger.kernel.org
Subject: Automatically re-running commands during an interactive rebase or post commit
Date: Mon, 29 May 2023 14:38:40 +0100 [thread overview]
Message-ID: <CACoUkn7TmZ=trtDKcQm0SG5qCqK=-+YxrDV-7xYnLH_XK7K7og@mail.gmail.com> (raw)
Hi all,
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?
Many thanks,
Paul
next reply other threads:[~2023-05-29 13:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-29 13:38 Paul Jolly [this message]
2023-05-29 13:41 ` Automatically re-running commands during an interactive rebase or post commit 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
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='CACoUkn7TmZ=trtDKcQm0SG5qCqK=-+YxrDV-7xYnLH_XK7K7og@mail.gmail.com' \
--to=paul@myitcv.io \
--cc=git@vger.kernel.org \
/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).