CODEWITHSUNDEEP
git
calys
calys

Reputation: 371

Git: Building project with multiple branches

I have a (large) Fortran project under Git. There are different active branches, corresponding to features under development. I would like to find a convenient way of maintaining a compiled version of the code for each branch.

The code is currently compiled using Make and all the object files are kept in a separate folder (like build_branch1) along with the binaries. The directory structure is like this:

Makefile
./src
./build_branch1/objects
./build_branch1/bin
./build_branch2/objects
./build_branch2/bin
...

In principle, I can therefore compile all the branches like this:

git checkout branch1
make --prefix=build_branch1
git checkout branch2
make --prefix=build_branch2
etc...

Make compares the timestamps of the sources (freshly checked out by Git) with the object files in the build_branchN folder and recompiles those that have changed. The problem is that Git changes the timestamps of all the source files that differ between branch1 and branch2, so that many files are re-compiled when they wouldn't need to be. Since the code takes a long time to compile (up to 30 minutes), this can be a major inconvenience.

I was wondering what should be the best strategy in this case. I am thinking of updating the timestamps after each checkout, like in this post: What's the equivalent of use-commit-times for git? What would you recommend?

Upvotes: 3

Views: 468

Answers (1)

VonC
VonC

Reputation: 1323963

Instead of modifying timestamp on each checkout, you could use a mechanism which wasn't around at the time of those answers (including mine): git notes.

You could:

  • after each build, a note the commit built with the build timestamp
  • before each build, look for a note (in a namespace named after the branch) for the last build timestamp and modify any file (which isn't currently being modified, according to git status) with that timestamp.

The idea is to record the information you need:

  • in the Git repo (so it can persists)
  • in a way which doesn't change the current history (the SHA1 of the commits aren't modified)

Upvotes: 3

Related Questions