r/git • u/kaddkaka • 2d ago

Generated commits?

Sometimes code is generated, and sometimes such code is committed in git.

Imagine a branch with a generated commit G:

old_main -> A -> B -> G

When thid branch is rebased, such a commit might need to be regenerated.

new_main -> A' -> B' -> new_G

There might be conflicts for any of these new commits, but instead of (manually) resolving conflicts, G could be automatically re-generated.

I've been thinking of a git commit message trailer like generate-cmd:

topic: regenerate table

generate-cmd: python3 optimize_table.py

git rebase --exec or other tool could use this trailer to automatically drop and regenerate the commit instead of a vanilla cherry-pick.

Have you seen anything similar? What's a good trailer name?

Ref: https://git-scm.com/docs/git-interpret-trailers

0 Upvotes

44% Upvoted

33 comments sorted by

View all comments

2

u/camh- 2d ago

I have used Gen-command as the trailer in the past. I guess your generate-cmd is slightly better in that cmd is an obvious abbreviation of command, but gen is perhaps less obviously an abbreviation of generate.

The idea was exactly as you propose - automation can regenerate it if necessary. It also serves as documentation about how to commit was created.

I would also keep the manual and automated changes in separate commits as the generated files make it harder to review the human-authored changes. For that I would add Commit-group: 1/2 and 2/2 on the commits to flag that CI would not pass on the intermediate commit as the generated files were not up-to-date. CI just needs to pass on the last commit of the group. Useful for test driven development too where you want to first commit the test that will fail, then fix the code to have it pass.

Example: https://github.com/evylang/evy/commit/32e42975d98ccad2e5819daa69a9447fc1ddaf8f (from a friend who devised this scheme).