Question

Situation: Our company creates software releases that are built using Hudson from code in a git repository. Sometimes, we need to reproduce a build of a previous version because a trial period has expired. This poses a problem since we need to find the code version corresponding to that software version. Our developers do not work using tags or branches, as it does not fit our working style.

As a solution to this problem, I thought we should include an automated tagging system every time a build is succesful.

The workflow I had in mind is the follwoing (executed on our build-machine):

1. Toss all local changes if any were made: git checkout . git clean -df
2. Get latest version: git pull
3. Go to desired version git checkout . or git checkout <tag>
4. Build software
5. If successful: tag current version, and push tag to repository: git tag -m "automated tag" versionXXX git push --tags

I have 3 questions regarding this way of working:

1. Are there any obvious flaws in this way of working? (Vague, I know – sorry)
2. For this usecase, is there any advantage to using annotated tags over lightweight tags? Most posts recommend annotated tags, but I’m not really seeing the added value, especially for this use case.
3. Our software consists of multiple modules, each having their own git repository. Some of these modules hardly get updated. Is there any downside to having a lot of tags pointing to the same commit?

Answer 1

1) Are there any obvious flaws in this way of working? (Vague, I know – sorry)

Nope.

2) For this usecase, is there any advantage to using annotated tags over lightweight tags?

No, if you’re not putting anything meaningful into the tag message, there’s no real point in creating one in the first place. There is no real disadvantage (they hardly use up any space).
If you get any results from the build, you could put those in the tag comment (unless you have other logging mechanisms which are checked anyway), e.g. number of warnings, or something like that.

3) Is there any downside to having a lot of tags pointing to the same commit?

Nope, other than possibly cluttering up the tag namespace (a tag name must be unique to the repo), there’s no problem. As mentioned, they hardly use any space.
If redundant tags are any problem, you could implement a strategy like: If the tag of the previous build points to the same commit I’d like to tag right now, don’t tag it. If you look up the tag for a specific version, use the tag with the latest version before the one you’re specifying. (That’s only feasible if the lookup is automated; otherwise just re-tag the commit.)