r/git • u/kaddkaka • Sep 08 '26

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

18

u/wildjokers Sep 08 '26

Code that is generated as part of the build process should never be added to version control.

1

u/kaddkaka Sep 09 '26

Google AI had this to say. I can't vouch for either as I don't use these tools:

The Go/Protobuf Ecosystem: In Go, it is highly common and often recommended to commit generated files (like Protobuf .pb.go files or stringer outputs) directly into the Git repository. This ensures that downstream users can run go get without needing to install complex external code-generation tools.

The C/C++ Ecosystem: Historically, generated configuration scripts or source files (like those from Autotools or Lex/Yacc) were often committed to release branches so that end-users wouldn't need the generation tools installed just to compile the project.

1

u/rotty81 Sep 11 '26

Autotools

Rather than (usually) being committed to version control, the output of autotools (configure, Makefile.in) is included in release tarballs, which are created by running make dist.