github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-19 14:42:41 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Tags missing on master since v1.1.0 #1363

New Issue
Closed
opened 2025-11-02 03:57:56 -06:00 by GiteaMirror · 15 comments
GiteaMirror commented 2025-11-02 03:57:56 -06:00
Owner
Copy Link

Originally created by @silverwind on GitHub (Dec 14, 2017).

I noticed that since v1.1.0, release tags are no longer picked up by git describe (and in turn show wrong in the interface footer). For example, from the current GitHub master:

$ git clone git@github.com:go-gitea/gitea.git .
$ git describe --tags
v1.1.0-894-g1687aa59

What's weird is that the missing tags do show on git tag:

$ git tag | tail -1
v1.3.2

Anyone know what's up?

Originally created by @silverwind on GitHub (Dec 14, 2017). I noticed that since v1.1.0, release tags are no longer picked up by `git describe` (and in turn show wrong in the interface footer). For example, from the current GitHub master: ````console $ git clone git@github.com:go-gitea/gitea.git . $ git describe --tags v1.1.0-894-g1687aa59 ```` What's weird is that the missing tags *do* show on `git tag`: ````console $ git tag | tail -1 v1.3.2 ```` Anyone know what's up?
GiteaMirror added the topic/build label 2025-11-02 03:57:56 -06:00
GiteaMirror commented 2025-11-02 03:57:57 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Dec 14, 2017):

Looks like this cause is that master is no longer tagged since v1.1.0, meaning the tags only exist on branches:

$ git log --graph --all --decorate | grep tag:
| * commit bdf18560110ac642c196054be38729760a4bbc39 (tag: v1.3.2, origin/release/v1.3)
| * commit 81fd8c8fb686621acfdd91a73ade75b44030ce18 (tag: v1.3.1)
| * commit 974cffead9b8e6bb554ea458a90aac8203907a55 (tag: v1.3.0)
| * commit 751f01936b5796fe77dbf8e9356cc5bd380914eb (tag: v1.3.0-rc2)
| * commit 4683e540ad504ca96346fff34f686ee2a1f2cd5c (tag: v1.3.0-rc1)
| * commit 09bd05732de61930c99509ee5a25816895f430a8 (tag: v1.2.3, origin/release/v1.2)
| * commit d81cf34e37657ca0dba28ff45389ee341d90deb0 (tag: v1.2.2)
| * commit 46bb1cf0262a38ffdbdf25bb3da3bf564ccdaff8 (tag: v1.2.1)
| * commit ed07d8a3081759ab078ece41340d4a84d30f83fd (tag: v1.2.0)
| * commit 03ff7687e02b86b956fffc74fb2ab66430cd96d1 (tag: v1.2.0-rc3)
| * commit fc0c6f48c7c7d3a476974a27cc9de79fa08a79e0 (tag: v1.2.0-rc2)
| * commit bbb0b8c17c0554c525c6e5c6cfb71aa62d0abb93 (tag: v1.2.0-rc1)
| * commit 34182c87ec50f647fc6f5b97ba201c3bd42f0728 (tag: v1.1.4, origin/release/v1.1)
| * commit 5bb20be8b2c88ec063a8ebb730d3ed4be9ad456d (tag: v1.1.3)
| * commit bbe6aa349ff0c87e5fefe3dfbc6e16c7c1cb2795 (tag: v1.1.2)
| * commit f9859a29913a4fddbdd9f67febef3553ddf8c98b (tag: v1.1.1)
* commit 1d652913425c5e296d60e6ee268a2c1f59a3379a (tag: v1.1.0)
| * commit e2c8d6fcb2c4073ed5cf164d88e7b5d44d95943c (tag: v1.0.2)
| * commit 155fb93b9b1cee976c852a0ae7540911630c18b8 (tag: v1.0.1)
* commit 6aacf4d2f09631359b99df562b4bf31dcef44ea3 (tag: v1.0.0)
* | commit 6bcff7828f117af8d51285ce3acba01a7e40a867 (tag: v0.9.99)

Would it be possible to tag master on each release too, so that this footer is updated when building from source?

screen shot 2017-12-14 at 20 37 29
@silverwind commented on GitHub (Dec 14, 2017): Looks like this cause is that `master` is no longer tagged since v1.1.0, meaning the tags only exist on branches: ````console $ git log --graph --all --decorate | grep tag: | * commit bdf18560110ac642c196054be38729760a4bbc39 (tag: v1.3.2, origin/release/v1.3) | * commit 81fd8c8fb686621acfdd91a73ade75b44030ce18 (tag: v1.3.1) | * commit 974cffead9b8e6bb554ea458a90aac8203907a55 (tag: v1.3.0) | * commit 751f01936b5796fe77dbf8e9356cc5bd380914eb (tag: v1.3.0-rc2) | * commit 4683e540ad504ca96346fff34f686ee2a1f2cd5c (tag: v1.3.0-rc1) | * commit 09bd05732de61930c99509ee5a25816895f430a8 (tag: v1.2.3, origin/release/v1.2) | * commit d81cf34e37657ca0dba28ff45389ee341d90deb0 (tag: v1.2.2) | * commit 46bb1cf0262a38ffdbdf25bb3da3bf564ccdaff8 (tag: v1.2.1) | * commit ed07d8a3081759ab078ece41340d4a84d30f83fd (tag: v1.2.0) | * commit 03ff7687e02b86b956fffc74fb2ab66430cd96d1 (tag: v1.2.0-rc3) | * commit fc0c6f48c7c7d3a476974a27cc9de79fa08a79e0 (tag: v1.2.0-rc2) | * commit bbb0b8c17c0554c525c6e5c6cfb71aa62d0abb93 (tag: v1.2.0-rc1) | * commit 34182c87ec50f647fc6f5b97ba201c3bd42f0728 (tag: v1.1.4, origin/release/v1.1) | * commit 5bb20be8b2c88ec063a8ebb730d3ed4be9ad456d (tag: v1.1.3) | * commit bbe6aa349ff0c87e5fefe3dfbc6e16c7c1cb2795 (tag: v1.1.2) | * commit f9859a29913a4fddbdd9f67febef3553ddf8c98b (tag: v1.1.1) * commit 1d652913425c5e296d60e6ee268a2c1f59a3379a (tag: v1.1.0) | * commit e2c8d6fcb2c4073ed5cf164d88e7b5d44d95943c (tag: v1.0.2) | * commit 155fb93b9b1cee976c852a0ae7540911630c18b8 (tag: v1.0.1) * commit 6aacf4d2f09631359b99df562b4bf31dcef44ea3 (tag: v1.0.0) * | commit 6bcff7828f117af8d51285ce3acba01a7e40a867 (tag: v0.9.99) ```` Would it be possible to tag master on each release too, so that this footer is updated when building from source? <img width="284" alt="screen shot 2017-12-14 at 20 37 29" src="https://user-images.githubusercontent.com/115237/34010925-a2833ef4-e10e-11e7-9da9-910069206792.png">
GiteaMirror commented 2025-11-02 03:57:57 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Dec 14, 2017):

No we can not tag master as it is way ahead and there is already PRs merged for next major release

@lafriks commented on GitHub (Dec 14, 2017): No we can not tag master as it is way ahead and there is already PRs merged for next major release
GiteaMirror commented 2025-11-02 03:57:57 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Dec 14, 2017):

I'd be fine with removing the version number and just showing the commit hash. I see that https://try.gitea.io already has such a version in the footer:

screen shot 2017-12-14 at 21 28 39

But when I build from the git source, I seem to always get the output of git describe --tags in my footer. I wonder if try.gitea.io is built differently, hmm.

@silverwind commented on GitHub (Dec 14, 2017): I'd be fine with removing the version number and just showing the commit hash. I see that https://try.gitea.io already has such a version in the footer: <img width="199" alt="screen shot 2017-12-14 at 21 28 39" src="https://user-images.githubusercontent.com/115237/34012956-fc337746-e115-11e7-9e78-feff91e2e67a.png"> But when I build from the git source, I seem to always get the output of `git describe --tags` in my footer. I wonder if `try.gitea.io` is built differently, hmm.
GiteaMirror commented 2025-11-02 03:57:57 -06:00
Author
Owner
Copy Link

@strk commented on GitHub (Dec 15, 2017):

Commit has is part of the git-describe output (final part, after the "g").
In general, tagging before branching would fix this problem.
I think the procedure described in the documente added by PR https://github.com/go-gitea/gitea/pull/2609 (HOWTO_RELEASE) would give us that.

@strk commented on GitHub (Dec 15, 2017): Commit has is part of the git-describe output (final part, after the "g"). In general, tagging *before* branching would fix this problem. I think the procedure described in the documente added by PR https://github.com/go-gitea/gitea/pull/2609 (HOWTO_RELEASE) would give us that.
GiteaMirror commented 2025-11-02 03:57:58 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Dec 15, 2017):

At most we could tag RC1 on master but I don't see much point in that

@lafriks commented on GitHub (Dec 15, 2017): At most we could tag RC1 on master but I don't see much point in that
GiteaMirror commented 2025-11-02 03:57:58 -06:00
Author
Owner
Copy Link

@sapk commented on GitHub (Dec 15, 2017):

If we want to put tag on master we should consider master has stable and use a develop branch (currently master branch) but that is not the same git flow than currently.

@sapk commented on GitHub (Dec 15, 2017): If we want to put tag on master we should consider master has stable and use a develop branch (currently master branch) but that is not the same git flow than currently.
GiteaMirror commented 2025-11-02 03:57:58 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Dec 17, 2017):

Tag before branch would definitely work as the tag is also visible on the branch, see below example workflow:

$ git init
$ git commit --allow-empty -m "first"
[master (root-commit) 8829b85] first
$ git tag v1.0.0 -m v1.0.0
$ git commit --allow-empty -m "second"
[master f6f310f] second
$ git describe
v1.0.0-1-gf6f310f
$ git branch branch
Branch 'branch' set up to track local branch 'master' by rebasing.
$ git checkout branch
Switched to branch 'branch'
Your branch is up to date with 'master'.
$ git describe
v1.0.0-1-gf6f310f
@silverwind commented on GitHub (Dec 17, 2017): Tag before branch would definitely work as the tag is also visible on the branch, see below example workflow: ```console $ git init $ git commit --allow-empty -m "first" [master (root-commit) 8829b85] first $ git tag v1.0.0 -m v1.0.0 $ git commit --allow-empty -m "second" [master f6f310f] second $ git describe v1.0.0-1-gf6f310f $ git branch branch Branch 'branch' set up to track local branch 'master' by rebasing. $ git checkout branch Switched to branch 'branch' Your branch is up to date with 'master'. $ git describe v1.0.0-1-gf6f310f
GiteaMirror commented 2025-11-02 03:57:58 -06:00
Author
Owner
Copy Link

@sapk commented on GitHub (Jun 1, 2018):

Just the rethinking of it as 1.5.0 release iscoming.

I agree with @silverwind we could also tag master before but it will work only for major release 1.5.0 (that could be enough to mark progress) but we could not add minor tag 1.5.1 to master as it will differ from branch release where it should be.

I propose another solution, couldn't we tag master as 1.5.0-dev and 1.6.0-dev after releasing 1.5.0 ?
This way we know that it is a dev version of 1.X and will be consistent with default tag used without make env. https://github.com/go-gitea/gitea/blob/master/main.go#L24

@sapk commented on GitHub (Jun 1, 2018): Just the rethinking of it as 1.5.0 release iscoming. I agree with @silverwind we could also tag master before but it will work only for major release 1.5.0 (that could be enough to mark progress) but we could not add minor tag 1.5.1 to master as it will differ from branch release where it should be. I propose another solution, couldn't we tag master as 1.5.0-dev and 1.6.0-dev after releasing 1.5.0 ? This way we know that it is a dev version of 1.X and will be consistent with default tag used without make env. https://github.com/go-gitea/gitea/blob/master/main.go#L24
GiteaMirror commented 2025-11-02 03:57:59 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Jun 1, 2018):

Tagging master branch for 1.x.0 version would mean that it would be frozen for 2-3 weeks more after rc1 for new features while we get out stable version

@lafriks commented on GitHub (Jun 1, 2018): Tagging master branch for 1.x.0 version would mean that it would be frozen for 2-3 weeks more after rc1 for new features while we get out stable version
GiteaMirror commented 2025-11-02 03:57:59 -06:00
Author
Owner
Copy Link

@sapk commented on GitHub (Jun 1, 2018):

Yes, that why I suggest 1.X.0-dev to show that it is a dev version as better alternative.

@sapk commented on GitHub (Jun 1, 2018): Yes, that why I suggest 1.X.0-dev to show that it is a dev version as better alternative.
GiteaMirror commented 2025-11-02 03:57:59 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jan 25, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Jan 25, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
GiteaMirror commented 2025-11-02 03:58:00 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 25, 2019):

This is still a problem

@lunny commented on GitHub (Jan 25, 2019): This is still a problem
GiteaMirror commented 2025-11-02 03:58:00 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Jan 25, 2019):

@lunny I think it is not as we now add 1.X.0-dev tags to master

@lafriks commented on GitHub (Jan 25, 2019): @lunny I think it is not as we now add 1.X.0-dev tags to master
GiteaMirror commented 2025-11-02 03:58:01 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jan 25, 2019):

Yes, I think it is resolved. On master:

$ git describe
v1.7.0-dev-92-g6b0c2e9e3
@silverwind commented on GitHub (Jan 25, 2019): Yes, I think it is resolved. On master: ``` $ git describe v1.7.0-dev-92-g6b0c2e9e3 ```
GiteaMirror commented 2025-11-02 03:58:01 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jan 25, 2019):

The master should be v1.8.0-dev :)

@lunny commented on GitHub (Jan 25, 2019): The master should be v1.8.0-dev :)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label topic/build
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#1363
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?