Wrong version of git.commit.id.describe

[Enigo]

We use 2.2.0 plugin version with "generateGitPropertiesFile" property set to "true" and recently faced a really weird situation. I'll do my best to describe it correctly.
The main problem is that git.commit.id.describe field is wrong in generated properties file. I can tell that because "git describe" command returns different version, e.g.
git describe --> 16.2.1.1-SNAPSHOT
but in file:

git.closest.tag.name=16.1.1.2-SNAPSHOT
git.commit.id.describe-short=16.1.1.2-SNAPSHOT-194
git.build.version=16.2.1.1-SNAPSHOT
git.commit.id.describe=16.1.1.2-SNAPSHOT-194-g1bea26a
git.commit.id=1bea26ad9a3187bf64d28a22aa5a74880a292e1b

So, how that happened? We perform project releases via Jenkins and the problem was caused by some merge conflicts because of versions in different branches.
We did some changes in branch for 16.1 release (with version 16.1.1.2) and then merge that branch into current master where version was 16.2.1.1. So, the merge conflict happened and resolved but after that the problem above appeared. When I checkout to the commit prior to the merge everything works just fine. But on merge-commit and after "git.commit.id.describe" is wrong.
Hope I explained it clear) Tell me if you need more details.

[TheSnoozer]

What is the output of git describe --long?
Is useNativeGit set in the pom?

[Enigo]

Here is the configuration:

<plugin>
   <groupId>pl.project13.maven</groupId>
      ...
      <configuration>
       <dateFormat>dd.MM.yyyy '@' HH:mm:ss z</dateFormat>
       <verbose>false</verbose>
       <failOnNoGitDirectory>false</failOnNoGitDirectory>
       <gitDescribe>
           <always>true</always>
           <abbrev>7</abbrev>
           <forceLongFormat>true</forceLongFormat>
       </gitDescribe>
       <generateGitPropertiesFile>true</generateGitPropertiesFile>
       <generateGitPropertiesFilename>${project.build.directory}/classes/git.properties
       </generateGitPropertiesFilename>
   </configuration>
</plugin> 

And here is the output:
$ git describe --long ---> 16.2.1.1-SNAPSHOT-165-g1bea26a

[TheSnoozer]

Could you also run git describe --long --tags for me please?

I'm assuming you are currently running in the situation that is outlined in the readme in the section git-describe and a small "gotcha" with tags.

Change your config with the following:

<gitDescribe>
           <tags>true</tags>
           <always>true</always>
           <abbrev>7</abbrev>
           <forceLongFormat>true</forceLongFormat>
       </gitDescribe>

and let me know if this changes the situation.

[Enigo]

$ git describe --long --tags returns the same 16.2.1.1-SNAPSHOT-165-g1bea26a

Configuration change has not affected the generated file.

Dunno if it's relevant but we use Git v.1.9.5

[TheSnoozer]

On the Jenkins do you perform a shallow clone or a full clone of the repo?
Also speaking of We perform project releases via Jenkins I'm not sure if this could be related to the following issue:
#235

Does usage of native git change the situation?

<configuration>
   ....
   <useNativeGit>true</useNativeGit>
   ....
</configuration>

can you send me the output of
git log --date-order --graph --tags --simplify-by-decoration --pretty=format:'%ai %h %d'

As of now I have tried to reproduce this with the following setup:
master (16.2.1.1) and branch (16.1.1.2).
create tag 16.2.1.1-SNAPSHOT in master.
create a README.txt in both and perform some changes in branch (16.1.1.2) for that file.
create tag 16.1.1.2-SNAPSHOT in branch so branch HEAD = this tag
When I want to merge branch to master I should get merge conflict resolve it.
Now in master I should get 16.2.1.1-SNAPSHOT but you'll get 16.1.1.2-SNAPSHOT - correct?

[Enigo]

I didn't find the Jenkins clone settings so I assume the default behaviour is used.

Yes, with <useNativeGit>true</useNativeGit> the git.commit.id.describe is correct (the same as git describe) --> 16.2.1.1-SNAPSHOT-165-g1bea26a

git log --date-order --graph --tags --simplify-by-decoration --pretty=format:'%ai %h %d' output:

* 2016-10-03 02:50:36 -0700 b16f13e  (tag: 16.3.1.1-SNAPSHOT) 
* 2016-10-03 02:19:07 -0700 b7f095e  (tag: 16.2.1.2) 
* 2016-09-30 00:39:35 -0700 dc9f0d3  (tag: 16.2.1.2-SNAPSHOT) 
* 2016-09-30 00:07:09 -0700 a5dd338  (tag: 16.2.1.1) 
*   2016-09-15 17:08:38 +0300 1bea26a  (HEAD) 
|\ 
| * 2016-09-15 10:46:17 +0300 61ec8b6  (origin/release-16.1) 
| * 2016-08-10 06:51:48 -0700 7b20d97  (tag: 16.1.1.2-SNAPSHOT) 
| * 2016-08-10 06:20:30 -0700 ee79076  (tag: 16.1.1.1) 
* |   2016-08-08 12:24:06 +0300 724470a 
|\ \ 
| |/ 
* | 2016-08-05 05:05:21 -0700 9b66c3c  (tag: 16.2.1.1-SNAPSHOT) 
* | 2016-08-05 04:34:07 -0700 6f40078  (tag: 16.2.1.0) 
| * 2016-08-05 02:35:36 -0700 9fbe608  (tag: 16.1.1.1-SNAPSHOT) 
| * 2016-08-05 02:35:08 -0700 ade5a5a  (tag: 16.1.1.0) 
|/ 
* 2016-08-01 11:59:08 -0700 ed2d2d5  (tag: 16.1.1.0-SNAPSHOT) 

The reproduction steps seems to be correct, although the tags are generated by Jenkins.

Regarding #235, well, yes, we use maven-release-plugin, should I do some changes in its configuration?

[TheSnoozer]

So far I was not able to reproduce the situation.
TL;DR;
I have created a bash script that creates a git repository that looks like your's when executing the command I forwarded.

Bash-Skript:

#!/bin/bash
MAIN_GIT_FOLDER=/tmp/sampleGit
MERGE_CONFLICT_FILE=${MAIN_GIT_FOLDER}/README.txt
ONLY_IN_BRANCH_FILE=${MAIN_GIT_FOLDER}/BRANCH.txt
BRANCH_NAME="release-16.1"

function changeAndCommitFile {
    FILE="$1"
    DATE="$2"

    echo `date +%s.%N` > ${FILE}
    git add ${FILE}

    git commit --date "${DATE}" -m "msg"
}

function changeAndCommitFileAndTag {
    FILE="$1"
    DATE="$2"
    TAG="$3"

    changeAndCommitFile "${FILE}" "${DATE}"
    GIT_COMMITTER_DATE="${DATE}" git tag ${TAG}
}

function mergeBranch {
    DATE="$1"
    BRANCH="$2"
    GIT_COMMITTER_DATE="${DATE}" git merge ${BRANCH} -m "merge"
}

rm -rf ${MAIN_GIT_FOLDER}
mkdir -p ${MAIN_GIT_FOLDER}
cd ${MAIN_GIT_FOLDER}

git init

# * 2016-08-01 11:59:08 -0700 ed2d2d5  (tag: 16.1.1.0-SNAPSHOT)
changeAndCommitFileAndTag "${MERGE_CONFLICT_FILE}" "2016-08-01 11:59:08 -0700" "16.1.1.0-SNAPSHOT"

# | * 2016-08-05 02:35:08 -0700 ade5a5a  (tag: 16.1.1.0) 
git checkout -b ${BRANCH_NAME}
changeAndCommitFileAndTag "${ONLY_IN_BRANCH_FILE}" "2016-08-05 02:35:08 -0700" "16.1.1.0"

# | * 2016-08-05 02:35:36 -0700 9fbe608  (tag: 16.1.1.1-SNAPSHOT) 
changeAndCommitFileAndTag "${ONLY_IN_BRANCH_FILE}" "2016-08-05 02:35:36 -0700" "16.1.1.1-SNAPSHOT"

# * | 2016-08-05 04:34:07 -0700 6f40078  (tag: 16.2.1.0)
git checkout master
changeAndCommitFileAndTag "${MERGE_CONFLICT_FILE}" "2016-08-05 04:34:07 -0700" "16.2.1.0"

# * | 2016-08-05 05:05:21 -0700 9b66c3c  (tag: 16.2.1.1-SNAPSHOT) 
changeAndCommitFileAndTag "${MERGE_CONFLICT_FILE}" "2016-08-05 05:05:21 -0700" "16.2.1.1-SNAPSHOT"

# * |   2016-08-08 12:24:06 +0300 724470a 
# changeAndCommitFile "${MERGE_CONFLICT_FILE}" "2016-08-08 12:24:06 +0300"
mergeBranch "2016-08-08 12:24:06 +0300" ${BRANCH_NAME}

# | * 2016-08-10 06:20:30 -0700 ee79076  (tag: 16.1.1.1)
git checkout ${BRANCH_NAME}
changeAndCommitFileAndTag "${ONLY_IN_BRANCH_FILE}" "2016-08-10 06:20:30 -0700" "16.1.1.1"

# | * 2016-08-10 06:51:48 -0700 7b20d97  (tag: 16.1.1.2-SNAPSHOT) 
changeAndCommitFileAndTag "${ONLY_IN_BRANCH_FILE}" "2016-08-10 06:51:48 -0700" "16.1.1.2-SNAPSHOT"

# | * 2016-09-15 10:46:17 +0300 61ec8b6  (origin/release-16.1)
# HEAD of branch -> produce conflict here
changeAndCommitFile "${MERGE_CONFLICT_FILE}" "2016-09-15 10:46:17 +0300"

# *   2016-09-15 17:08:38 +0300 1bea26a  (HEAD) 
git checkout master
mergeBranch "2016-09-15 17:08:38 +0300" ${BRANCH_NAME}
# "merge" & conflict resolution by just overriding the file again :-)
changeAndCommitFile "${MERGE_CONFLICT_FILE}" "2016-09-15 17:08:38 +0300"

# * 2016-09-30 00:07:09 -0700 a5dd338  (tag: 16.2.1.1) 
changeAndCommitFileAndTag "${MERGE_CONFLICT_FILE}" "2016-09-30 00:07:09 -0700" "16.2.1.1"

# * 2016-09-30 00:39:35 -0700 dc9f0d3  (tag: 16.2.1.2-SNAPSHOT) 
changeAndCommitFileAndTag "${MERGE_CONFLICT_FILE}" "2016-09-30 00:39:35 -0700" "16.2.1.2-SNAPSHOT"

# * 2016-10-03 02:19:07 -0700 b7f095e  (tag: 16.2.1.2) 
changeAndCommitFileAndTag "${MERGE_CONFLICT_FILE}" "2016-10-03 02:19:07 -0700" "16.2.1.2"

# * 2016-10-03 02:50:36 -0700 b16f13e  (tag: 16.3.1.1-SNAPSHOT) 
changeAndCommitFileAndTag "${MERGE_CONFLICT_FILE}" "2016-10-03 02:50:36 -0700" "16.3.1.1-SNAPSHOT"

# fin
git log --date-order --graph --tags --simplify-by-decoration --pretty=format:'%ai %h %d'

This is how git log --date-order --graph --tags --simplify-by-decoration --pretty=format:'%ai %h %d' looks:

* 2016-10-03 02:50:36 -0700 c2d1b56  (tag: 16.3.1.1-SNAPSHOT, master)
* 2016-10-03 02:19:07 -0700 65fc5cb  (tag: 16.2.1.2)
* 2016-09-30 00:39:35 -0700 ec1d6b3  (tag: 16.2.1.2-SNAPSHOT)
* 2016-09-30 00:07:09 -0700 97108d5  (tag: 16.2.1.1)
*   2016-09-15 17:08:38 +0300 32ff343  (HEAD)
|\  
| * 2016-09-15 10:46:17 +0300 6319d8c  (release-16.1)
| * 2016-08-10 06:51:48 -0700 8d75c1f  (tag: 16.1.1.2-SNAPSHOT)
| * 2016-08-10 06:20:30 -0700 5b5d0df  (tag: 16.1.1.1)
* |   2016-10-07 23:53:13 +0200 d32636b 
|\ \  
| |/  
* | 2016-08-05 05:05:21 -0700 1f23eec  (tag: 16.2.1.1-SNAPSHOT)
| * 2016-08-05 02:35:36 -0700 635015a  (tag: 16.1.1.1-SNAPSHOT)
* | 2016-08-05 04:34:07 -0700 73c5f39  (tag: 16.2.1.0)
| * 2016-08-05 02:35:08 -0700 a26d28a  (tag: 16.1.1.0)
|/  
* 2016-08-01 11:59:08 -0700 22d766d  (tag: 16.1.1.0-SNAPSHOT)

my current pom to run the test with the 2.2.0 plugin looks like

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.sonatype.oss</groupId>
        <artifactId>oss-parent</artifactId>
        <version>9</version>
    </parent>

    <groupId>com.example</groupId>
    <artifactId>example</artifactId>
    <packaging>jar</packaging>
    <version>0.0.0</version>
    <name>example test</name>

    <licenses>
        <license>
            <name>GNU Lesser General Public License 3.0</name>
            <url>http://www.gnu.org/licenses/lgpl-3.0.txt</url>
        </license>
    </licenses>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>

        <java.target>1.7</java.target>
    </properties>

    <dependencies>

    </dependencies>

    <build>
        <!-- GIT COMMIT ID PLUGIN CONFIGURATION -->
        <resources>
            <resource>
                <directory>src/main/resources</directory>
                <filtering>true</filtering>
                <includes>
                    <include>**/*.properties</include>
                    <include>**/*.xml</include>
                </includes>
            </resource>
        </resources>
        <testResources>
            <testResource>
                <directory>src/test/resources</directory>
                <excludes>
                    <exclude>_git_*/**</exclude>
                    <exclude>README.md</exclude>
                </excludes>
            </testResource>
        </testResources>

        <plugins>
            <!-- if you would like to run the git-commit-id-plugin for your build, 
                you could also include it here instead using a profile (see README.md) -->
            <!-- Setting built-in java compiler properties -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.1</version>
                <configuration>
                    <source>${java.target}</source>
                    <target>${java.target}</target>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <profiles>
        <profile>
            <id>demo</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>pl.project13.maven</groupId>
                        <artifactId>git-commit-id-plugin</artifactId>
                        <version>2.2.0</version>
                        <!-- optional to change the phases of the individual mojo's -->
                        <executions>
                            <execution>
                                <id>get-the-git-infos</id>
                                <goals>
                                    <goal>revision</goal>
                                </goals>
                            </execution>
                        </executions>
                        <configuration>
                            <verbose>true</verbose>
                            <dotGitDirectory>/tmp/sampleGit/.git</dotGitDirectory>
                            <useNativeGit>false</useNativeGit>
                            <injectAllReactorProjects>true</injectAllReactorProjects>
                            <gitDescribe>
                                <tags>true</tags>
                                <always>true</always>
                                <abbrev>7</abbrev>
                                <forceLongFormat>true</forceLongFormat>
                            </gitDescribe>
                            <generateGitPropertiesFile>true</generateGitPropertiesFile>
                            <generateGitPropertiesFilename>${project.build.directory}/classes/git.properties</generateGitPropertiesFilename>
                            <failOnNoGitDirectory>false</failOnNoGitDirectory>
                            <failOnUnableToExtractRepoInfo>true</failOnUnableToExtractRepoInfo>
                        </configuration>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-antrun-plugin</artifactId>
                        <version>1.7</version>
                        <executions>
                            <execution>
                                <phase>process-resources</phase>
                                <id>default-cli</id>
                                <configuration>
                                    <target>
                                        <echo>${git.commit.id.describe}</echo>
                                    </target>
                                </configuration>
                                <goals>
                                    <goal>run</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>
</project>

When I'm on HEAD (in my current git tree this would be 32ff343; in yours 1bea26a)

$ git describe --long --tags
16.1.1.2-SNAPSHOT-5-g32ff343

$ mvn clean process-resources -Pdemo -Dmaven.test.skip=true
[echo] 16.1.1.2-SNAPSHOT-5-g32ff343

When I'm on 97108d5 (tag: 16.2.1.1) in your tree 61ec8b6 (origin/release-16.1)

$ git describe --long --tags
16.2.1.1-0-g97108d5

$ mvn clean process-resources -Pdemo -Dmaven.test.skip=true
[echo] 16.2.1.1-0-g97108d5

From my side this looks how it should be.
Anything missing in this setup?

[TheSnoozer]

What be be also worth trying:
Use latest version from central:
https://search.maven.org/#artifactdetails%7Cpl.project13.maven%7Cgit-commit-id-plugin%7C2.2.1%7Cmaven-plugin

<dependency>
    <groupId>pl.project13.maven</groupId>
    <artifactId>git-commit-id-plugin</artifactId>
    <version>2.2.1</version>
</dependency>

and try clone the (git) repository and build the latest 2.2.2-SNAPSHOT version and see if the issue is still present....

[Enigo]

Wow, that looks really cool)
Unfortunately, the latest plugin version hasn't affected the situation.
And reproduction steps seems valid. But anyway even if I use configs (maven-antrun-plugin included) from your post I get wrong version.
BTW I just notice, that the
git.commit.id.describe=16.1.1.2-SNAPSHOT-194-g1bea26a-dirty
has that dirty at the end. But when I run git describe there is not. Dunno if it's relevant tho.

Not much help but some logs when I set verbose to true:

[INFO] git.closest.tag.name 16.3.1.1-SNAPSHOT 
[INFO] Tag refs [Ref[refs/tags/16.1.1.2-SNAPSHOT=14bb58096dfb6ddc55664360cda832f7a8efeff9], Ref[refs/tags/16.2.1.0=48ffd5efbc4ba84df8eb97409ee142b33c9ecd66], 
Ref[refs/tags/16.2.1.1=42c1c0ec5cb991b6f49e6c0092f595fdc7ea44f7], Ref[refs/tags/16.2.1.1-SNAPSHOT=aaad2691d172f4856de5536c86f90a85fdaa4c98], Ref[refs/tags/16.2.1.2=26974782a552e51f063b97663a396df6226537e5], Ref[refs/tags/16.2.1.2-SNAPSHOT=f66c67575a12607ba13322c 
95921c5b648245945], Ref[refs/tags/16.3.1.1-SNAPSHOT=db639587aae78726faa1b5ad49ffb8fcfcc63bd2]


[INFO] Resolved tag [16.1.1.2-SNAPSHOT] [PersonIdent[username, [email protected], Wed Aug 10 08:01:52 2016 -0700]], points at [commit 7b20d97e80d1c836f7922434b533c3daa08a0c4a 0 ------] 
[INFO] Resolved tag [16.2.1.0] [PersonIdent[username, [email protected], Fri Aug 5 04:49:42 2016 -0700]], points at [commit 6f400782a875dccdbe17b5ea076cb1a218b12af9 0 ------] 
[INFO] Resolved tag [16.2.1.1] [PersonIdent[username, [email protected], Fri Sep 30 00:23:58 2016 -0700]], points at [commit a5dd33823df44942deff272657769567a55a6e0b 0 ------] 
[INFO] Resolved tag [16.2.1.1-SNAPSHOT] [PersonIdent[username, [email protected], Fri Aug 5 06:18:20 2016 -0700]], points at [commit 9b66c3c02e3b40d961009d3016bae48ef9ea9b0a 0 ------] 
[INFO] Resolved tag [16.2.1.2] [PersonIdent[username, [email protected], Mon Oct 3 02:34:45 2016 -0700]], points at [commit b7f095e96b45f2299428a17847549e88d993ad88 0 ------] 
[INFO] Resolved tag [16.2.1.2-SNAPSHOT] [PersonIdent[username, [email protected], Fri Sep 30 01:50:00 2016 -0700]], points at [commit dc9f0d3fa5b42c71204b1652cc948381cc9a0920 0 ------] 
[INFO] Resolved tag [16.3.1.1-SNAPSHOT] [PersonIdent[username, [email protected], Mon Oct 3 04:01:40 2016 -0700]], points at [commit b16f13eb8fff302643280f6c3439a80123f9de6e 0 ------] 


[INFO] key [commit b16f13eb8fff302643280f6c3439a80123f9de6e 0 ------], tags => [[DatedRevTag{id=db639587aae78726faa1b5ad49ffb8fcfcc63bd2, tagName='16.3.1.1-SNAPSHOT', date=October 3, 2016 2:01:40 PM +03:00}]] 
[INFO] key [commit 9b66c3c02e3b40d961009d3016bae48ef9ea9b0a 0 ------], tags => [[DatedRevTag{id=aaad2691d172f4856de5536c86f90a85fdaa4c98, tagName='16.2.1.1-SNAPSHOT', date=August 5, 2016 4:18:20 PM +03:00}]] 
[INFO] key [commit 7b20d97e80d1c836f7922434b533c3daa08a0c4a 0 ------], tags => [[DatedRevTag{id=14bb58096dfb6ddc55664360cda832f7a8efeff9, tagName='16.1.1.2-SNAPSHOT', date=August 10, 2016 6:01:52 PM +03:00}]] 

[TheSnoozer]

I'm closing this since I couldn't reproduce.
if you can provide a reproducer or encounter this issue again feel free to open another ticket ;-)

[Enigo]

Yeah, sure. Anyway, after I set useNativeGit to true this issue never reproduced.

[TheSnoozer]

Mhh thats interesting....
usenativeGit uses the native git binaries....so this sounds like that there is a bug inside the jgit-implementation...I'll try to investigate further (hate to close issues with "can not reproduce")

[Enigo]

I wish I could help you more. Tell me if I can!

[Enigo]

Well, funny enough searching for git-commit-id-plugin wrong revision got me back to this issue :D
many years later I'm again facing something very similar, but it is a different project now.
I've performed a very complex history rewrite on a big old project (>50k+ commits) and now git.commit.id.describe-short returns some very random commit from the past.
As it was before, git describe --long --tags returns the expect version. And also all other metadata looks correct

[INFO] evalCommit is [0543ec4e7b4db2a0265b49d6d0d48d400bb4aba3]
[INFO] Collected git.commit.id.describe with value 20.11-6367-g0543ec4-dirty
[INFO] Collected git.commit.id.describe-short with value 20.11-6367-dirty
[INFO] Collected git.commit.id with value 0543ec4e7b4db2a0265b49d6d0d48d400bb4aba3
[INFO] Collected git.commit.id.abbrev with value 0543ec4
[INFO] Collected git.dirty with value true

0543ec4e7b4db2a0265b49d6d0d48d400bb4aba3 is indeed the commit I expect to see

Luckily, this time it was that infamous small gotcha with tags

as per the original issue - it's been a very long time since I opened it, so suggest we close it now.

[TheSnoozer]

Hi, while this may still be an issue in the plugin it's impossible to reproduce/debug without a public repository. i understand that you don't want to share private company repositories....well as outlined above without the ability to debug I now decided to finally put this on the graveyard as can't reproduce.
I'm sorry.

if you ever bump into this again with a public repo where there the issue can be reproduced, please be invited to create a new issue with the relevant details.