Release targeting wrong branch after deleting another release with the same tag but different branch #10175

New Issue

GiteaMirror · 2025-11-02T09:00:16-06:00

GiteaMirror commented

2025-11-02 09:00:16 -06:00

Originally created by @KroneCorylus on GitHub (Jan 29, 2023).

Description

Steps to reproduce:

In a repository with at least 2 branches one with some changes (in this example: main branch, test branch) create a release 1.0.0@test (1.0.0 tag name, test branch).
Delete the created release.
Create a new release with the same tag but in the correct branch 1.0.0@main

Expected behaviour:
The last release and tag should show the changes/commits made on the branch main.
Observed behaviour:
The release show the changes made on the test branch even when the release says is targeting the main branch and shows negative commits like this:

More Info:
the main branch has a empty readme file
the test branch has 2 commits changing the readme file
the tag 1.0.0 show the file with the changes made on test branch
if a click on the "-2 commits" the "Compare commits" screen shows no changes.

Gitea Version

1.18.3 and 1.19.0 (gitea demo)

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Debian Linux and Try.gitea.io

How are you running Gitea?

The issue can be replicated both on my docker installation of giteo and in https://try.gitea.io/

Database

None

Originally created by @KroneCorylus on GitHub (Jan 29, 2023). ### Description Steps to reproduce: 1. In a repository with at least 2 branches one with some changes (in this example: main branch, test branch) create a release 1.0.0@test (**1.0.0** tag name, **test** branch). 2. Delete the created release. 3. Create a new release with the same tag but in the correct branch 1.0.0@main Expected behaviour:     The last release and tag should show the changes/commits made on the branch main. Observed behaviour:     The release show the changes made on the test branch even when the release says is targeting the main branch and shows negative commits like this: ![image](https://user-images.githubusercontent.com/26716702/215309430-8acfe096-dcb6-4e8a-a455-81ba066547d4.png) More Info: [the main branch has a empty readme file](https://try.gitea.io/krone/TestRelease/src/branch/main/README.md) [ the test branch has 2 commits changing the readme file](https://try.gitea.io/krone/TestRelease/src/branch/test/README.md) [the tag 1.0.0 show the file with the changes made on test branch](https://try.gitea.io/krone/TestRelease/src/tag/1.0.0) if a click on the "-2 commits" the "Compare commits" screen shows no changes. ![image](https://user-images.githubusercontent.com/26716702/215309619-390a5bda-5244-46d0-8964-2519d8eeeeb1.png) ### Gitea Version 1.18.3 and 1.19.0 (gitea demo) ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System Debian Linux and Try.gitea.io ### How are you running Gitea? The issue can be replicated both on my docker installation of giteo and in https://try.gitea.io/ ### Database None

GiteaMirror added the type/bug label 2025-11-02 09:00:16 -06:00

GiteaMirror closed this issue

2025-11-02 09:00:16 -06:00

GiteaMirror commented

2025-11-02 09:00:17 -06:00

@Zettat123 commented on GitHub (Feb 22, 2023):

Maybe the reason is that you didn't delete the existing tag. You could delete the 1.0.0 Tag first and then create the new release with the correct branch.

I will try to make an enhancement to optimize this process.

@Zettat123 commented on GitHub (Feb 22, 2023): Maybe the reason is that you didn't delete the existing tag. You could delete the **`1.0.0 Tag`** first and then create the new release with the correct branch. I will try to make an enhancement to optimize this process.

GiteaMirror commented

2025-11-02 09:00:17 -06:00

@KroneCorylus commented on GitHub (Feb 22, 2023):

Maybe the reason is that you didn't delete the existing tag. You could delete the 1.0.0 Tag first and then create the new release with the correct branch.

I will try to make an enhancement to optimize this process.

Deleting the release do not delete the tag? Im going to try what you told me a report back. Thanks

@KroneCorylus commented on GitHub (Feb 22, 2023): > Maybe the reason is that you didn't delete the existing tag. You could delete the **`1.0.0 Tag`** first and then create the new release with the correct branch. > > I will try to make an enhancement to optimize this process. Deleting the release do not delete the tag? Im going to try what you told me a report back. Thanks

GiteaMirror commented

2025-11-02 09:00:17 -06:00

@KroneCorylus commented on GitHub (Feb 23, 2023):

Yes you are correct. If after deleting the release you manually delete the tag, the new release is created correctly. Maybe if you choose a existing tag the branch selector should be disabled ?

@KroneCorylus commented on GitHub (Feb 23, 2023): Yes you are correct. If after deleting the release you manually delete the tag, the new release is created correctly. Maybe if you choose a existing tag the branch selector should be disabled ?

GiteaMirror commented

2025-11-02 09:00:18 -06:00

@Zettat123 commented on GitHub (Feb 23, 2023):

Yes you are correct. If after deleting the release you manually delete the tag, the new release is created correctly. Maybe if you choose a existing tag the branch selector should be disabled ?

Yes. If a tag exists, the selector should be disabled. I will implement this function.

@Zettat123 commented on GitHub (Feb 23, 2023): > Yes you are correct. If after deleting the release you manually delete the tag, the new release is created correctly. Maybe if you choose a existing tag the branch selector should be disabled ? Yes. If a tag exists, the selector should be disabled. I will implement this function.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10175