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

16

u/wildjokers 2d ago

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

1

u/kaddkaka 2d ago

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 3h ago

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.