I've checked with gbp dch and it seems to work fine - it treats commit
log as emacs rather than as git log :)
So we don't have to do anything about 0.9.5 and .6, pardon the noise.
On 14.12.2016 13:54, Neels Hofmeyr wrote:
- how can I
add tag '0.9.3' to commit
I made those tags recently, I also made a wiki
page:
https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
One may need the appropriate pushing powers on gerrit to set a tag?
Let me know if I should change access permissions...
Could be good to agree whom to allow tagging and some guidelines.
Above wiki page would be a good place to document such.
git log --tags --show-notes --decorate | grep
'tag:' | head
commit 9795cf1b126d5567dbd0a25b56e9ba75be9513c1 (tag: 0.9.5)
commit 3cc757df1822114bf446dc2d5f6a95da92321a25 (tag: 0.9.6)
commit 9c0751fc60e6282b5f5ff791d53f6f862f1c9c79 (tag: 3G_2016_09)
commit 3b6fb0880c3ab1e23a3d7d738d073b00c2a794c2 (tag: 0.9.4)
commit abc46af90fde9e9435dee5f4f472aec3f68d3353 (tag: 0.9.3)
In the revision history, 0.9.5 comes before 0.9.6, but 0.9.6 has an earlier
commit date.
This comes from to the way git does rebases: the commit's date remains the same
as the original commit time. Most of our log history has wildly jumping dates.
I'm not sure whether we will or should get rid of that.
So, my guess is: the way the tags were created doesn't matter. We can't
re-order the way they are displayed as long as the two *commits* that are
tagged (whenever) keep the same dates:
2016-12-08 17:47 <0.9.6>
2016-12-10 17:01 <0.9.5>
I can think of ways to work around it, sort of like
$ git log --tags --show-notes --decorate | grep 'tag:' | sort -k 1.54 -r -V |
head
commit 9c0751fc60e6282b5f5ff791d53f6f862f1c9c79 (tag: 3G_2016_09)
commit 3cc757df1822114bf446dc2d5f6a95da92321a25 (tag: 0.9.6)
commit 9795cf1b126d5567dbd0a25b56e9ba75be9513c1 (tag: 0.9.5)
commit 3b6fb0880c3ab1e23a3d7d738d073b00c2a794c2 (tag: 0.9.4)
commit abc46af90fde9e9435dee5f4f472aec3f68d3353 (tag: 0.9.3)
(though it would be good to filter on signed tags as well)
The most important question: do we have an actual use case where this wrong
ordering breaks anything?
~N
--
Max Suraev <msuraev(a)sysmocom.de>
http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte