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

[Son Luong Ngoc <sluongng@gmail.com>]

Hey Paul,

On Mon, May 29, 2023 at 3:44 PM Paul Jolly <paul@myitcv.io> wrote:
>
> Hi all,
>
> I would appreciate some advice on the best way to solve the following problem.
>
...
>
> 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?

In general, there are 2 cases that you would want to handle:
1. Inserting format directive in between commit rebase that DOES NOT
    come with merge conflicts
2. Same but DOES come with merge conflicts.

For (1), you might be interested in tools such as
- Git Absorb(a) that automatically fixup your stack of commits with your
  current dirty changes.
- Git Branchless(b) "git test" feature

Both of these tools are heavily influenced by Meta's internal Phabricator
mercurial workflow. Since the release of these tools, Meta has also
open-sourced their internal tool at Sapling SCM(c) which they touted
to be git-compatible.

For (2), and if none of the tools above solve your problem,
then I recommend using git-rebase interactive with a vim macro to
generate the needed rebase todo. You can find my comment in (d)
to see what such a rebase todo list would look like.

Tools such as Restack (e) take it a step further by providing a custom Git
`sequence.editor` to programmatically generate the rebase todo for you.
This could be a bash script, or a perl script... or a custom Go binary of
your choosing. You might want to go down this route if a vim macro is
not sufficient and you require some custom logic.

Finally, I would recommend turning on rerere.enabled (f) config to store
the conflict resolution for subsequent rebase attempts. This way, you would
only need to resolve each rebase conflict once.

(a): https://github.com/tummychow/git-absorb
(b): https://github.com/arxanas/git-branchless/wiki/Command:-git-test#fixing-formatting-and-linting-issues
(c): https://sapling-scm.com/docs/commands/absorb
(d): https://github.com/arxanas/git-branchless/discussions/45#discussioncomment-3364792
(e): https://github.com/abhinav/restack
(f): https://git-scm.com/docs/git-config#Documentation/git-config.txt-rerereenabled

>
> Many thanks,
>
>
> Paul

Cheers,
Son Luong.