11

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.

Community
  • 1
  • 1
Mark Booth
  • 7,605
  • 2
  • 68
  • 92
  • Can't help with Eclipse, but this my [Git-centric answer](http://programmers.stackexchange.com/a/142001/36934) on a similar problem can help somehow, I hope – Lazy Badger Mar 29 '12 at 18:08
  • Thanks @LazyBadger, but as I said in my referenced `hg` question (in the *rejected solutions* section), keyword expansion isn't a very good option these days. Plus, it's *so* 1980's. – Mark Booth Mar 29 '12 at 18:22
  • Something to remember about git -- if you have the hashtag you have no problem to "quickly build exactly the revision". The hashtag in git is unique and points to just one set of source files thus if the code exists in a git repository that you have access to, with the hash tag you can build it. This makes `git describe` your solution. – Hogan Apr 02 '12 at 16:00
  • @Hogan - I don't need all of the other information that `git describe` provides, all I'm interested in is the commit hash (which is what `git rev-parse HEAD` provides) and to know whether the working copy is clean, which is information that neither `git describe` nor `git rev-parse` provides. – Mark Booth Apr 02 '12 at 16:16
  • @Hogan - By clean, I mean that when you do a `git status` on the repository, you get back `nothing to commit (working directory clean)`. One of the things I want the About information to include is whether there have been modifications since the last commit, so I intend to simulate the Mercurial convention of adding a + to the end of the commit hash to indicate that. – Mark Booth Apr 02 '12 at 16:36
  • `git describe --dirty` adds a suffix to the resulting description if the working tree is dirty, `-dirty` by default. – Daniel Roethlisberger Apr 02 '12 at 16:42
  • @DanielRoethlisberger - Thanks, now I just need to work out how to get rid of that unwanted tag, shame that's the primary function of `git describe`. *8') – Mark Booth Apr 02 '12 at 17:06
  • If you never tag anything you won't have to worry about them annoying you. – Hogan Apr 02 '12 at 17:26
  • (I would never have considered that as your meaning of clean vs dirty because I would never have a deployment to production that was not checked into source control. Maybe this is the root of your problem.) – Hogan Apr 02 '12 at 17:28
  • @Hogan - In an ideal world, I agree, but sometimes we have to be pragmatic. I work in an environment where minor fixes to live systems may need to be quick and dirty. My intention here is to limit the scope of this potential confusion. Incidentally, *clean* and *dirty* are pretty commonly used terms with `git`, see the [Git Book Glossary](http://book.git-scm.com/7_glossary.html). My concern re tagging is that tags *are* used and I don't want a possibly inappropriate tag muddying the waters. In many ways using `git describe --all --dirty=+` to get the branch might be of more use. – Mark Booth Apr 02 '12 at 17:49
  • This has been [covered before][1]. [1]: http://stackoverflow.com/questions/62264/dealing-with-svn-keyword-expansion-with-git-svn#72874 – Michael Slade Apr 09 '12 at 15:11
  • @MichaelSlade - As I said to LazyBadger and in my referenced `hg` [question](http://stackoverflow.com/q/2386440/42473) (in the rejected solutions section), keyword expansion isn't a very good option these days and your referenced answer just re-inforces my view on this. – Mark Booth Apr 11 '12 at 10:10

2 Answers2

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.

sharakan
  • 6,821
  • 1
  • 34
  • 61
  • I will accept this for the moment, but if a better answer comes along later (especially one which answers all three aspects of my question) then I will switch my accept to that one instead). – Mark Booth Apr 11 '12 at 10:13
1

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)

Sathyajith Bhat
  • 21,321
  • 22
  • 95
  • 134
mkleehammer
  • 72
  • 2