Question

How do you manage generated source code files in you repositories and deployment routines with Git (PHP, Python, etc)?

For example, I have a repository named “interfaces” with Thrift definitions in it. They can be converted to Python, PHP, JS, etc skeletons/stubs. Other projects in different languages, each in its own repository, want to use those stubs. How to deliver the stubs to the projects?

I see only two ways:

1. Generate the stub files and store them in the “interfaces” repository, and this repository should be attached to the projects’ ones (as readonly submodule or any other way). But this way introduces a lot of headaches when checking out the updates to the interfaces and the stubs due to overcomplicated “git submodules” concepts.

2. Attach pure “interfaces” repository to each project, and generate stub files as temporary git-ignorable(!) files (with “make stubs” or alike). This way, each project can have their own generation settings with their own patches applied (if needed at all). But you need to introduce some compilation commands to PHP/Python development and production environments (not just “git pull”).

What are the pros and cons of these approaches?

Answer 1

It is generally best to favour the “generation” route over the “storing generated content” route, mainly because you are not always 100% sure of the current status of said generated content: is it in sync with the sources?

A post-receive hook can take care, upon a push, of generating the relevant content.
See Git Hooks or Pro-Git hooks.
On your own local instance though, (i.e. on a git pull), an alias might combine both pulling and generating said content.