Gitea and OpenID #986

Closed
opened 2025-11-02 03:44:23 -06:00 by GiteaMirror · 4 comments
Owner

Originally created by @andreacappelli on GitHub (Aug 21, 2017).

Hi,
I tried to setup gitea 1.1.3 with OpenID but with no luck, OpenID tab never shown

So I build gitea from source (branch master, commit 5c29b0a5fe) and with the same app.ini OpenID is shown and works

The strange is that in the bottom bar the version shown is 1.1.0+498-g5c29b0a, which seems earlier

So I have 2 question:

  • When OpenID will be released?
  • Is the version number in branch master broken (showing an earlier release number)?
Originally created by @andreacappelli on GitHub (Aug 21, 2017). Hi, I tried to setup gitea 1.1.3 with OpenID but with no luck, OpenID tab never shown So I build gitea from source (branch master, commit 5c29b0a5fe1a124572ccaa55bd79fee2ce894253) and with the same app.ini OpenID is shown and works The strange is that in the bottom bar the version shown is 1.1.0+498-g5c29b0a, which seems earlier So I have 2 question: - When OpenID will be released? - Is the version number in branch master broken (showing an earlier release number)?
Author
Owner

@andreacappelli commented on GitHub (Aug 21, 2017):

Sorry I didn't read
https://github.com/go-gitea/gitea/issues/2328
which is the response to question 1

@andreacappelli commented on GitHub (Aug 21, 2017): Sorry I didn't read https://github.com/go-gitea/gitea/issues/2328 which is the response to question 1
Author
Owner

@lafriks commented on GitHub (Aug 21, 2017):

version number is not broken, it is correct when building master

@lafriks commented on GitHub (Aug 21, 2017): version number is not broken, it is correct when building master
Author
Owner

@strk commented on GitHub (Aug 22, 2017):

It is indeed confusing that 1.1.0+498-g5c29b0a > 1.1, but what those
numbers mean is that there are 498 commits after the branch point
for 1.1.0.

For comparison, 1.1.3 has 31 commits from that point:

git log --oneline v1.1.0..v1.1.3  | wc -l

We could reduce the confusion by adding another tag only
reachable from the master branch and not from the 1.1 branch,
to represent first commit in the 1.2 space. Something like:

git tag 1.2-start d87596aec4da6b32a980d782cc8c4e6ba92fc867

Then git describe --tags would return:

1.2-start-498-g2c6a0fdc

@strk commented on GitHub (Aug 22, 2017): It is indeed confusing that 1.1.0+498-g5c29b0a > 1.1, but what those numbers mean is that there are 498 commits *after* the branch point for 1.1.0. For comparison, 1.1.3 has 31 commits from that point: git log --oneline v1.1.0..v1.1.3 | wc -l We could reduce the confusion by adding another tag only reachable from the master branch and not from the 1.1 branch, to represent first commit in the 1.2 space. Something like: git tag 1.2-start d87596aec4da6b32a980d782cc8c4e6ba92fc867 Then `git describe --tags` would return: 1.2-start-498-g2c6a0fdc
Author
Owner

@andreacappelli commented on GitHub (Aug 22, 2017):

Hi @strk,
yesterday I check the code and found the git describe part, 498 and g5c29b0a were ok

I was confused because I thought that master branch had all tag and not only the first one of the x.y branch, but that make sense (it's the last common before x.y was created and the branch diverged)

Tagging the start of the new development cycle on the master branch would of course disambiguate better

Thanks for you reply

@andreacappelli commented on GitHub (Aug 22, 2017): Hi @strk, yesterday I check the code and found the git describe part, 498 and g5c29b0a were ok I was confused because I thought that master branch had all tag and not only the first one of the x.y branch, but that make sense (it's the last common before x.y was created and the branch diverged) Tagging the start of the new development cycle on the master branch would of course disambiguate better Thanks for you reply
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#986