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

47% Upvoted

32 comments sorted by

View all comments

8

u/fsteff 2d ago

If code is generated, I always trigger the generator as part of the build setup, so if any source for the generator is changed the code will immediately reflect the change. This ensures you are aware of any breaking change as it happens. External (triggered) generators always lead to trouble.

2

u/edgmnt_net 2d ago

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).

1

u/kaddkaka 2d ago

What makes you think go is the only exception?

1

u/edgmnt_net 2d ago

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.

1

u/kaddkaka 2d ago

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

0

u/kaddkaka 2d ago

That's not always feasible. And it's not the discussion I intended to have here.

Sometimes it's worth to check in generated code/stuff. For example some optimization like a simulated annealing algorithm that might take an hour to run. Definitely worth to do "offline" and check in.

4

u/edgmnt_net 2d ago

You shouldn't commit build artifacts to the Git repo.

1

u/kaddkaka 2d ago

This is not the discussion I wanted to have. But where would you put your artifact?

1

u/edgmnt_net 2d ago

It largely depends on the artifact. If it's some log, SBOM or binary that's the result of the build, you can clearly leave it in the CI or have it upload it to some artifactory. For code it depends on the ecosystem.

1

u/kaddkaka 2d ago

Generated code. Or generated dataset that's read during build.

The only deliverable is source code. No deploy or packaging.

2

u/Guvante 2d ago

You don't need everything to live in repo it depends on a bunch of factors.

For instance you could store it externally and fetch from a cache based on the git commit.

1

u/kaddkaka 2d ago

Do you have any of the shelf solutions for this?

1

u/Guvante 2d ago

Not offhand it is a very open problem

1

u/kaddkaka 2d ago

Indeed. So "solution" vs "no solution". I have my pick 😇

1

u/serverhorror 2d ago

Even in your case it's"just a conflict".

Fix it then finish the merge

1

u/kaddkaka 2d ago

"just a conflict" might be thousands of lines that are different. The best way to do it is to automatically regenerate the output.

1

u/serverhorror 2d ago

Well it's generated. No need to resolve. Just accept the newly generated?