`git describe`

[Rainer Müller]

On 2016-11-28 12:43, René J.V. Bertin wrote:
> I checked: the release-2.3 branch has seen only a single commit after
> v2.3.5, all other commits done since were done on the master branch
> after the 2.3 branch was merged. If there's a good reason not to
> apply the tag to the main branch (too) I fail to see it. What I don't
> know is how you'd apply the tag to the branch too. Presumably not by
> merging master back into the branch after creating the release tag,
> because apparently that doesn't work the other way either.

The release was done from the release-2.3 branch, which has diverged
from the master branch. There is no way to merge either branch to the
other. I do not see any importance in getting this tag to the master branch.

Fact is, master is not something on top of v2.3.5, so your expected
output would not be correct either. Instead, master contains many
commits that were only partially cherry-picked to the release-2.3 branch.

>> I don't see how that would change anything for 'git describe', if
>> this is only done on a branch.
> 
> I guess we'd have to understand exactly what `git describe` does. A
> scripted sequence of commands does make it easier not to mess it up;
> I wouldn't be surprised for instance if the order of `git push $2`
> and `git push --tags $2` has some kind of importance.

'git help describe' tells you:
"The command finds the most recent tag that is reachable from a commit."

The most recent tag reachable from the HEAD of master is v2.0.0-beta1.

What exactly are we trying to solve here?
Why do we need to discuss this?

Rainer