Missing information on "merge into/pull from" dropdown on a forked repo #10042

New Issue

GiteaMirror · 2025-11-02T08:56:37-06:00

GiteaMirror commented

2025-11-02 08:56:37 -06:00

Originally created by @dloez on GitHub (Jan 2, 2023).

Description

Coming from this solved issue, when you fork a repository and transfer its ownership to the owner of the parent fork and create a pull request on the forked repository, the base repository is marked as the default target in the dropdown "merge into", which works well. If you then click on the "merge into" dropdown, you can see the different branches from the different repositories that can be selected:
See attached "Screenshot 1".

The issue comes when you click on one of the branches of the forked repo on the dropdown, everything works well but if you click one more time on the "merge into" dropdown, only the owner of the repository and the branch name can be seen, making it difficult to differentiate between which branch is on which repository.
See attached "Screenshot 2".

I guess that in image 2 it should be:

lopezd:test -> lopezd/base-repo-fork:test
lopezd:main -> lopezd/base-repo-fork:main
lopezd:main -> lopezd/base-repo:main

And in the first image it would be useful to have:

lopezd:main -> lopezd/base-repo:main
lopezd:test -> lopezd/base-repo-fork:test
lopezd:main -> lopezd/base-repo-fork:main

This has been reproduced at https://try.gitea.io/:

Gitea Version

1.17.4

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

Screenshot 1

Screenshot 2

Git Version

No response

Operating System

No response

How are you running Gitea?

Docker image
https://try.gitea.io/

Database

SQLite

Originally created by @dloez on GitHub (Jan 2, 2023). ### Description Coming from this [solved issue](https://github.com/go-gitea/gitea/issues/6318), when you fork a repository and transfer its ownership to the owner of the parent fork and create a pull request on the forked repository, the base repository is marked as the default target in the dropdown "merge into", which works well. If you then click on the "merge into" dropdown, you can see the different branches from the different repositories that can be selected: See attached "Screenshot 1". The issue comes when you click on one of the branches of the forked repo on the dropdown, everything works well but if you click one more time on the "merge into" dropdown, only the owner of the repository and the branch name can be seen, making it difficult to differentiate between which branch is on which repository. See attached "Screenshot 2". I guess that in image 2 it should be: - lopezd:test -> lopezd/base-repo-fork:test - lopezd:main -> lopezd/base-repo-fork:main - lopezd:main -> lopezd/base-repo:main And in the first image it would be useful to have: - lopezd:main -> lopezd/base-repo:main - lopezd:test -> lopezd/base-repo-fork:test - lopezd:main -> lopezd/base-repo-fork:main This has been reproduced at [https://try.gitea.io/](https://try.gitea.io/): - https://try.gitea.io/lopezd/base-repo - https://try.gitea.io/lopezd/base-repo-fork ### Gitea Version 1.17.4 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots Screenshot 1 ![image](https://user-images.githubusercontent.com/40007435/210214292-49049175-caee-46ce-9d86-416b4644dc0a.png) Screenshot 2 ![image](https://user-images.githubusercontent.com/40007435/210214520-54e21cc8-3590-499e-909e-3b7fb0bf973e.png) ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? - Docker image - https://try.gitea.io/ ### Database SQLite

GiteaMirror added the type/bug label 2025-11-02 08:56:37 -06:00

GiteaMirror closed this issue

2025-11-02 08:56:37 -06:00

GiteaMirror commented

2025-11-02 08:56:38 -06:00

@lunny commented on GitHub (Jan 16, 2023):

I think it should be failed when move a fork to any user/org which have contains a parent or child fork repository.

@lunny commented on GitHub (Jan 16, 2023): I think it should be failed when move a fork to any user/org which have contains a parent or child fork repository.

GiteaMirror commented

2025-11-02 08:56:38 -06:00

@dloez commented on GitHub (Jan 17, 2023):

Is there any reason not to allow an organization/user to fork an owned repository?

@dloez commented on GitHub (Jan 17, 2023): Is there any reason not to allow an organization/user to fork an owned repository?

GiteaMirror commented

2025-11-02 08:56:39 -06:00

@dloez commented on GitHub (Jun 28, 2023):

Is there any reason not to allow an organization/user to fork an owned repository?

I would still like to receive an answer to this question.

@dloez commented on GitHub (Jun 28, 2023): > Is there any reason not to allow an organization/user to fork an owned repository? I would still like to receive an answer to this question.

GiteaMirror commented

2025-11-02 08:56:39 -06:00

@lunny commented on GitHub (Jun 29, 2023):

Is there any reason not to allow an organization/user to fork an owned repository?

I think the idea is derived from Github?

@lunny commented on GitHub (Jun 29, 2023): > Is there any reason not to allow an organization/user to fork an owned repository? I think the idea is derived from Github?

GiteaMirror commented

2025-11-02 08:56:39 -06:00

@dloez commented on GitHub (Jun 29, 2023):

Yes, it is. But I was again not able to find any reasons on why it is the way it is.
My thoughts on this are, if Gitea has a feature that some users (like us and many others) have found use cases for it and those use cases are not against any patterns/good practices/etc, why remove it?
As I said, if there is a specific reason to not do so, I would happily close this issue and would love to see this feature/bug removed.

@dloez commented on GitHub (Jun 29, 2023): Yes, it is. But I was again not able to find any reasons on why it is the way it is. My thoughts on this are, if Gitea has a feature that some users (like us and many others) have found use cases for it and those use cases are not against any patterns/good practices/etc, why remove it? As I said, if there is a specific reason to not do so, I would happily close this issue and would love to see this feature/bug removed.

GiteaMirror commented

2025-11-02 08:56:39 -06:00

@dloez commented on GitHub (Dec 16, 2024):

Closing as it was addressed in #22882

@dloez commented on GitHub (Dec 16, 2024): Closing as it was addressed in #22882

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#10042