`git describe`

[René J.V. Bertin]

On Monday November 28 2016 12:54:35 Rainer Müller wrote:

> 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.

The master branch does show the 2.3.5 commits, plus a series of commits on top of it.

> The most recent tag reachable from the HEAD of master is v2.0.0-beta1.
> 
> What exactly are we trying to solve here?

As said in my OP, it would be nice if the master branch described itself with a more appropriate tag. I presume it's meant to lead to a future new release, be it 2.3.6 or 2.4 or even 3. Either way it can only be something that comes after 2.3.5 and if calling it 2.3.5-N isn't perfect, 2.0.0-beta1-M is even less appropriate (and 2.4.0.N counter-productive).

This is moot if master is exclusively a testing area for experiments that may never make it to a release. If it has a more usual role and is used by those who live on the bleeding edge, then my point stands and translates into "it would be nice if one could refer to one's installed version by a standardised and monotonically increasing release/revision number rather than by a random commit hash".

Svn didn't have this problem because it uses commit counters rather than random hashes. I suppose you can say that's the problem I'm trying to solve.

> Why do we need to discuss this?

This may come as a surprise, but such "needs" can declare themselves when well-intended (or should I say naive?) users try to contribute things they consider useful which are then dismissed with just a few passing remarks. Give a good reason (= constructive counter-argument) immediately, or else admit no one feels like being bothered to address the issue, and there won't be any discussion. Not from me in any case, I know when to be stubborn and defend my arguments and when to accept the futility of insisting. (Ask my PhD director ... :) )

If you want a more elaborate answer: I see an application of this in the context of a MacPorts-devel port which could cater to users who'd like to follow the "base" development version but not necessarily the real bleeding edge. Presuming the MacPorts port is used to create the official installers: a -devel version could create snapshots that are more stable than daily builds. This is exactly what I've been doing locally, admittedly for a single snapshot only.

R