`git describe`

[Rainer Müller]

On 2016-11-28 13:41, René J.V. Bertin wrote:
> 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.

No, not at all. What you might see there are not the same commit
objects, as the changes were cherry-picked from master to release-2.3.

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

As you discovered yourself now, 'port version' of master identifies
itself as 2.3.99 at the moment.

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

There is no guarantee that something that is on master right now will
end up in 2.3.6, or in 2.4, or even any release at all.

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

With our current branching model, I do not see a way to solve this. Our
tags on the release-X.Y branches are just not reachable from master.

The only way I would see to make them reachable is to merge release-X.Y
back into master, while ignoring all actual code changes and conflicts.
This would only have the purpose of making the tag reachable.

Pro & contra:

- Wouldn't the conveyed information that master was based on a released
  vX.Y.Z be wrong?
+ This would allow us to eventually delete release-X.Y branches, since
  all commits are also reachable from master.

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

You did not start this thread with the intention of adding a commit hash
to 'port version'. You put out a question about 'git describe', but
apparently you did not even look up or understood what it does or how it
works. To this question, I could only tell you that it works as documented.

You included a reference to a git-release tool that somehow is meant to
do something differently, but that tool is not even in a standard git
installation. However, once looking into this, it is an easily
understood shell script. And turns out, it really does nothing different
than our ReleaseProcess documents.

Please excuse me if I got snarky after doing this stuff, which – in my
opinion – you could have worked out yourself by reading the appropriate
documentation and experimenting.

After going through this stuff, I was finally asking why this is even
relevant to MacPorts base. Maybe this was my misunderstanding, but up to
this point it was not obvious to me that you were going for a change to
the internal version identification and/or the 'port version' output.

To get back to MacPorts base, the relevant code that sets/extracts the
version information for 'port version' is in configure.ac:

https://github.com/macports/macports-base/blob/eb973fb6b7d387e539dcc614046ac619346c397d/configure.ac#L4

Rainer