15

I have a git question to which the answer might be "don't do it that way" but here goes: I want to have a little dialog box in my code (Matlab as it happens) which displays the current version. This is mostly for my benefit (as developer) to check what version the user is running for support. This is fairly standard and I have Matlab code to read the version from a text file and display it. The trick I want to achieve is to have Git automatically update version.txt on each commit.

The code I am using is a shell script in .git/hooks/pre-commit that essentially dumps the output of git describe to the file version.txt (with some formatting). I have tags for major and minor versions, and git describe essentially gives that info, plus the number of commits since the last tag.

The problem is that if I use the pre-commit hook, then version.txt points to the commit before the one that is committed, but if I use the post-commit hook, then version.txt is edited after the commit is made and only can be committed to a new commit, which edits version.txt again...

I could perhaps use a script in post-commit that adds version.txt and then does a git commit --amend --no-edit, but this seems a bit messy. I also don't know if the post-commit hook would be run on the amend, leading to an infinite loop.

The pre-commit hook can to edit the code files, and commit them, but doesn't know the commit description. Is there a way around this? Perhaps another hook that I haven't found? Could I make the post-commit hook run commit without causing an infinite loop, and if I could, is it a good idea?

Is there a better way of doing this?

Edit after comment: Note that my users do not have Git installed. They download a source code bundle from Gitlab and unzip to run the Matlab code. Hence any solution cannot run Git on the fly but must get the version ID (in whatever from) from Git and write it into a (committed) file somehow.

EdR
  • 503
  • 4
  • 13
  • 1
    What about a checkout-hook which creates this file? – tkausl Apr 12 '18 at 09:07
  • @tkausl Possible, but I think it wouldn't work in my use case, as the users download a zip file of source from Gitlab. Would a post checkout hook be applied correctly in that case? Thanks for pointing this out though, as I wasn't aware of checkout hooks. – EdR Apr 12 '18 at 09:33
  • Why not use the commit id instead? It may not be semantic, but at least there’s no extra work involved. – evolutionxbox Apr 12 '18 at 09:39
  • @evolutionxbox I could use commit id rather than `git describe` but the the key thing is getting it committed to a file in the repo as my users do not have git installed. I will edit the question to clarify. – EdR Apr 12 '18 at 09:42
  • The way to do it is not to increase version number on each commit. Instead increase version number on each tagging. That's the standard, when your code is ready to be published tag it with its version number. You have to be disciplined enough to **never give users non-tagged versions of code**, which, again, is standard industry practice. – slebetman Apr 12 '18 at 13:52
  • @slebetman Yes, thanks. That is that way I am doing it, and I could (I assume) get the tag into the version box. Download instructions are via the Gitlab "Tags" page. `git describe` just gives you the tag if the current commit is tagged but more information if it isn't tagged. Using the commit just seemed to be a more thorough approach in case a non-tagged version got out, and instinctively as easy as the using just the tag. It turns out it isn't... – EdR Apr 12 '18 at 18:41

2 Answers2

3

I found the answer by reading this question though I couldn't find it by searching, so I intend leaving this question open for now. What I originally intended is logically impossible: You can't have the hash of the current commit in any committed file. The hash depends on the file contents, and in my approach the file contents depend on the hash, giving a circular dependency.

I will need to change my approach.

Update for anyone else trying to solve a similar problem:

I have created a bash script deploy.sh that automates the process of creating a tag and adding the (tag) version number to a file in the codebase.

EdR
  • 503
  • 4
  • 13
0

Old post but i guess this can be usefull,

two way to fully automated the version number

Vincent
  • 56
  • 3