kdevelop git/master branch tag

[René J.V. Bertin]

On Monday August 29 2016 21:05:12 Sven Brauch wrote:

>> Well, a version number is purely information in a certain way, but
>> it's just practical to be able to use `git describe` to translate a
>> (random) commit hash to a monotonically increasing version number.
>
>Let me rephrase, it should be sufficient for "git describe" to pick it up.

Sure, but how does "git describe" know to pick up the fact that v5.0.0 was released in a recent past?
`git tag` does show me a v5.0.0 tag with was apparently set with Sven's commit that also changed the version number in the CMake file to 5.0.0 .

I just did a fresh clone, which also showed the v4.90.91 base for `git describe`. I then tried this:

%> git checkout 5.0
Branch 5.0 set up to track remote branch 5.0 from origin.
Switched to a new branch '5.0'
%> git describe
v5.0.0-8-g1e1a5eb

Which corresponds exactly to the number of commits since the v5.0.0 tag was created.
Is it possible that this was somehow pushed to a wrong branch, i.e. the origin/5.0 branch?

Simply adding a tag to the 1f9a3b1a53cf4803103aa670dabafa5f1b77df18 commit in the master branch doesn't change the output from git describe for me. Maybe this will help, from `git help tag`?

   On Re-tagging
       What should you do when you tag a wrong commit and you would want to re-tag?

       If you never pushed anything out, just re-tag it. Use "-f" to replace the old one. And you’re done.

       But if you have pushed things out (or others could just read your repository directly), then others will
       have already seen the old tag. In that case you can do one of two things:

        1. The sane thing. Just admit you screwed up, and use a different name. Others have already seen one
           tag-name, and if you keep the same name, you may be in the situation that two people both have "version
           X", but they actually have different "X"'s. So just call it "X.1" and be done with it.

        2. The insane thing. You really want to call the new version "X" too, even though others have already seen
           the old one. So just use git tag -f again, as if you hadn’t already published the old one.

       However, Git does not (and it should not) change tags behind users back. So if somebody already got the old
       tag, doing a git pull on your tree shouldn’t just make them overwrite the old one.

       If somebody got a release tag from you, you cannot just change the tag for them by updating your own one.
       This is a big security issue, in that people MUST be able to trust their tag-names. If you really want to
       do the insane thing, you need to just fess up to it, and tell people that you messed up. You can do that by
       making a very public announcement saying:

           Ok, I messed up, and I pushed out an earlier version tagged as X. I
           then fixed something, and retagged the *fixed* tree as X again.

           If you got the wrong tag, and want the new one, please delete
           the old one and fetch the new one by doing:

                   git tag -d X
                   git fetch origin tag X

           to get my updated tag.

           You can test which tag you have by doing

                   git rev-parse X

           which should return 0123456789abcdef.. if you have the new version.

           Sorry for the inconvenience.

       Does this seem a bit complicated? It should be. There is no way that it would be correct to just "fix" it
       automatically. People need to know that their tags might have been changed.