How can I add git hashes to my Eclipse RCP application About page?

Question

In the past, using mercurial with Visual Studio, I used to add mercurial changeset ids to my application so that when the user did a Help About, it would list all components and their exact mercurial revision. It would also log all changeset ids to the application log file every time it started up. This procedure even allowed me to see whether a particular working copy had been modified since the last commit (mercurial's hg id indicates a dirty working copy by adding a + to the end of the changeset id it reports).

This was incredibly useful, since it meant that any time a user reported a problem, I could quickly build exactly the revision they were using. I could also tell when people had snuck in a quick hack to fix a problem and had neither committed the changes nor told me about it.

I would now like to replicate the same facility in my git hosted RCP application. Unfortunately, I'm rather new to both git and Eclipse RCP application development, so I'm a little unclear as whether the same technique would work.

In particular I have been unable to work out how to do the equivalent of hg id with git , how to get the Eclipse build system to call git to create a .gitignored file containing the id, so that it can be compiled into the application/plug-in, or how to get this information into the Help>About page.

If you have done this, or something similar, I would love some pointers as to how you did it. Alternatively, I would be happy to hear any suggestions about alternative ways to achieve the end result that I seek.

---

With a little google-fu, reading behind the lines and experimentation, it looks like git rev-parse HEAD or git rev-parse --short HEAD is probably the closest to an hg id, alas I can't find a way to indicate that the working copy isn't clean, so it looks like I will have to check the output of a git status --short and if it isn't empty, append a + to the commit hash manually.

Now I just need to understand how to get these commands to be run from the Eclipse build system and where to inject this information so that it shows up in the About pages.

Answer 1

I can't speak to the git portion of this question, but I can to some extent on the RCP portion. That said, you've mentioned that you're not a fan of keyword substitution. I appreciate that, but as far as I know that's a very common practice throughout the RCP build framework!

The About dialog can be controlled using an about.properties, about.mappings, and about.ini file. The Rich Client Platform Book talks about this.

What I would do is have your build generate the about.mappings file with your git hashtag.

Answer 2

Have you looked at git describe?

http://linux.die.net/man/1/git-describe

I use this output for a number of different projects. It will give you the closest tag in the past, the number of commits since the tag, and a few characters from the hash.

Here is an example from the manpage: v1.0.4-14-g2414721

In this example, the parts are:

• the tag is 'v1.0.4'
• there have been 14 commits after the tag on this branch
• the hash prefix is 2414721

If the last commit is tagged, you'll get only the tag name: v1.0.4

There are lots of useful options, but the two that are most important to my projects are:

--tags: I use lightweight, unsigned tags which it doesn't pick up by default.

--match: If you have different types of tags but only want to match those that start with 'v'.

From a process point of view, what I do for serious projects is to also:

1. Change the version and count to an rc or beta format:

   tag v1.2-14 --> `1.3-rc14` or `1.3-beta14`
   

   You can't be building 1.2 since it is in the past, so it must be the 14th build of the next version which is 1.3.

2. Prepend the branch name if it is a special branch (not master, etc.) For example, "v1.2-14" on branch "featurex" would produce:

   featurex-1.3-rc14
   

3. Append -modified or `-unsupported" if the build doesn't have everything checked in. This is your clue that you will never be able to reproduce it.

    featurex-1.3-rc14-unsupported
   

4. Store the hash on the end or on the next line in logs or about screens. I normally put the full hash into logs and such, but the smaller prefix is common: featurex-1.3-rc14 (2414721) This works nicely with my workflow. When I merge the feature into a release branch, the prefix goes away: 1.3-rc14 (2414721)

When testing is complete and the version is tagged, the rc goes away: 1.3 (2414721)