Look for best # in tag history? about gradle-android-git-version HOT 2 CLOSED

Fixed in 0.4.0: use tagPattern to specify which tags are interesting and which are not. So in this case if your release branch is targeting 2.0 while your master branch targets 3.0, you could just add tagPattern /^3.*/ to the build config in master.

from gradle-android-git-version.

@gladed I'm not sure if I'm matching your original diagram, but for the sake of mine, assume that new development is being done on master, and therefore the version of the release branch is always lower than newer commits on master.

      1.0.0       1.1.0  [a]   [b]
master: *-----*-----*-----*-----*
               \                
release:        *-------------*  
              1.0.1         1.0.2 

In this state, the output of git describe on the commits tagged as 1.1.0 and 1.0.2 are straightforward (simply the tags themselves), and the output for commit [a] is 1.1.0-1-ga and commit [b] is 1.1.0-2-gb. Now, let's merge the changes made in 1.0.1 and 1.0.2 into master (so that those hot fixes make it into 1.1.+)

      1.0.0       1.1.0  [a]   [b]   [c]
master: *-----*-----*-----*-----*-----*
               \                     /
release:        *-------------*------
              1.0.1         1.0.2 

In my experience, the output of git describe on commit [c] is 1.1.0-5-gc (and not 1.0.2-5-gc) even though the 1.0.2 tag is "closer". Again, I'm not an expert on what's going on under the hood, but I can imagine a couple of ways git describe may have been designed so that it takes some number of factors into account in order to make sure it produces an accurate/helpful version description.

If what I've described is accurate, would the use of git describe help solve this issue? Or have I misunderstood the issue and/or diagram altogether?

from gradle-android-git-version.