3 ms·
Our company uses a tag, quite improperly, to indicate our "last successful build" on each branch, so our local builds can pull e.g. compiled .o files from that
by unholiness 4y ago
Our company uses a tag, quite improperly, to indicate our "last successful build" on each branch, so our local builds can pull e.g. compiled .o files from that build and speed up the local build process. A tag is improper since it needs to move with every successful build. All relevant commands need --force to update it and it can rarely create headaches when machines disagree.
I believe the right thing functionally is a child branch, updated automatically with either a merge or a force-push on new successful builds. But it feels not quite right conceptually, and it's harder to explain to new developers (who can already get overwhelmed with handling multiple branches). Is there a non-branch solution for having a moving unique label?
- avar 4y agoDon't clobber the branch or tag, instead create dated tags with a name like built-YYYYMMDD-HHMMSS. Then have downstream systems pick whatever the latest tag is. You can force push it, but why not keep a trail of what your past state was?
- unholiness 4y agoBecause the "downstream systems" you mention are just all local git commands. It is necessary to branch from these points, so creating branches and checking state requires them. So e.g. `git diff lsb/master` becomes `git diff lsb/master/built-YYYYMMDD-HHMMSS` or at least `git diff $(git merge-base master)`. That doesn't seem better than the occasional --force.
- avar 4y agoIt's better because you might be looking at the output of that, and then your co-worker tries to do the same, except you're looking at different because you force-pushed it. And you furthermore have no immutable record of what happened anymore. You can always create one tag that you force-push to point to the "latest tag" to make it convenient for one-liners, but not force-push any of the "real" ones.