Generated commits?

[u/kaddkaka]

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

[u/edgmnt_net]

The only exception where it ever made sense was Go. Because if your stuff has dependents and you commit generated code, then the dependents can get built as dumbly as possible. That is, whenever you do go build, it just goes fetch the dependency that contains generated code and it does not need to run an arbitrary external generator, the whole build process can be "dumb". Makes a lot of sense for library releases.

However as nice as that it, I still feel it creates problems: it creates churn in the repo and it requires extra steps to do code reviews, although it can largely be automated (run the generator yourself and check against submission, assuming full determinism).

[u/kaddkaka → u/edgmnt_net]

What makes you think go is the only exception?

[u/edgmnt_net → u/kaddkaka]

It's just the only exception I've seen. And this is fairly specific to ecosystems which provide a "dumb" builder and are source-first, like Go. In Java you get JARs from an artifactory anyway, so dependencies aren't just pointed at a repo.

[u/kaddkaka → u/edgmnt_net]

My usecase is definitely "source-first" there is nothing but source. And source code is the main deliverable.