How can a Git tag be aligned with the formatted PDF using gitinfo2?

Question

I think I do not understand the workflow of the gitinfo2 package correctly. The documentation says (shortend):

1. Edit and format abc.tex until ready for release
2. Commit the release version of abc.tex
3. Tag the release
4. checkout abc.pdf
5. Format & commit the release version of abc.pdf

My question: How can the Git tag be aligned with the formatted PDF? The described workflow is showing two commits... When I am following it, the given tag in the commit history is "one behind". As consequence: when checking out the version where the tag is given, the PDF does not contain the tag.

I do not see different behaviour when using smartgit or commandline tool git.

Is this supposed to be? Can somebody help me?

Thank you,

Thomas

Edit: Added picture to specify my question.

As shown in the screenshot (graphical log view of Smartgit) the commit where the tag is given and the commit where the pdf was added - containing the right release info - are not identical. --> When checking out "Release 1.34" the PDF has not the right info. Only the following commit contains a correct set of data.

Edit 2:

As current workaround I am moving the tag after the PDF commit as described in this post.

Answer 1

The main assumption is that abc.pdf is being tracked by git.

Here is a list of command line steps, that keeps the release number up to date (this assumes that abc.pdf has been committed at some point previously)

(start with clean repo, make changes to abc.tex and compile)

git add abc.tex
git commit -m "my commit message goes here"
git tag -a 1.34
git checkout abc.pdf
pdflatex  abc
git add abc.pdf
git commit -m "updated release number in pdf"

Here is the file I have used for abc.tex

\documentclass{article}
\usepackage[mark,grumpy]{gitinfo2}

% gitinfo2 settings
\renewcommand{\gitMark}{Release: \gitRel}

\begin{document}
hello world
\end{document}

One reason your release tag might not be as you intend could be because it isn't being picked up by

RELTAG=$(git describe --tags --long --always --dirty='-*' --match '[0-9]*.*' 2>/dev/null)` in the `.git/hooks/post-.*

files. If your tag starts with anything other than a number, then you need to change the --match part accordingly. For example, if your tag starts with a V, as in V3.2.2, then you might use

RELTAG=$(git describe --tags --long --always --dirty='-*' --match 'V[0-9]*.*' 2>/dev/null)` in the `.git/hooks/post-.*

Answer 2

Thanks for the support cmhughes!

I will wrap it up:

My question is a question related to git. gitinfo2 is supposed to work like this - that's fine for me.

Starting from here:

we can

• move the tag, as described in this post by doing

  git tag -fa 1.34

• or merge the commits (rebase) as described in this post.

  git rebase -i HEAD~2

and than change in the upcoming dialog (looks something like this):

pick 2840179 Changing abc.tex
pick 00d844f Adding abc.pdf

# Rebase 8c99d54..00d844f onto 8c99d54
#
....

the second pick (pointing to the last commit) into a squash.

This ends up in a (maybe) more nice history. However, we have to retag afterwards as well with git tag -fa 1.34. Otherwise we loose the tag...:

Thomas