Ancestroy Tags missing on develop/feature/release branches when using GitFlow about gradle-android-git-version HOT 5 CLOSED

I've been thinking more about this and I think, whether you're using git-flow or not, that a "mergeback" from your release branch into your master is a good idea.

In some cases, people make "hotfixes" to the release branch, and those need to be merged back into the mainline development branch anyhow. Once you've done this, android-git-version will be able to reach the most recent tagged commit, and will give you good version names.

Another way to do it is to tag your develop branch with the next version code pre-emptively.

For example:

develop: a --> b --> d (1.1-dev) ---------> f 
master:         \--> c (1.0) --> e (1.0.1)   \--> g (1.1)

Commit f will be called 1.1-dev-1 or something like it.

from gradle-android-git-version.

The best solution I have is tagPattern. It does require that on your master's build.gradle you modify the tagPattern once per major release.

Open to other ideas if anyone has them; it's a fundamental git limitation that the branch doesn't remember which commits it used to be on, only the commit it's on at the present time.

from gradle-android-git-version.

Note: I was able to work around the git-flow limitation by merging master into develop so that the tag ancestry was developed.

git fetch
git checkout develop
git merge master

Still wondering if there are any other "best practices" that I could apply when using git-flow. If not, feel free to close this issue.

from gradle-android-git-version.

Best practice: http://endoflineblog.com/gitflow-considered-harmful 😄

But seriously I'm glad you found a workaround. "Vanilla" git-flow doesn't have the tag in the necessary commit histories, as you observed, and I think your workaround is good.

from gradle-android-git-version.

I know this is quite old, but I'm hitting this problem right now.

Taking into account a similar case as the one described:

develop: a --> b --> d (1.1) -----------------m--> f 
master:         \--> c (1.0) --> e (1.0.1) --/      \--> g (1.1)

If there's a merge from master back to develop, then on commit f will be named 1.0, however using git describe the result is 1.1.

Is this the expected behaviour? If it is do you have any kind of workaround - besides a new tag on develop?

from gradle-android-git-version.