Gitea: No branches of fork visible on new Pull Request

[mxmehl]

• Gitea version (or commit ref): g52feff5a5
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [x] Yes (provide example URL)
  
  
  • [ ] No
  
  
  • [ ] Not relevant
  
  

Description

Since upgrading to 1.9.0, one cannot see branches of their fork any more when creating a new pull request upstream.

Example: In my fork of go-gitea/chardet on try.gitea.io, I have created the branch test-pr. When clicking on New Pull Request in the upstream repo, I cannot find my own branch there, only branches from the repo itself.

This is unusual behaviour and makes it hard for people to create a pull request. Not sure if it's a regression or an intended change though.

[lunny]

When you click the New Pull Request from your fork repo, that it is.

[mxmehl]

Isn't that a bit counter-intuitive? I want to create a pull request at upstream, not my fork.

This way, it's also harder to document for git beginners because the URL for creating pull requests is individual per user.

[lafriks]

This could definitely be improved, there should be issue about this imho already

[lunny]

We need a PR to do that.

[stale[bot]]

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]]

This issue has been automatically closed because of inactivity. You can re-open it if needed.

[jancborchardt]

Just ran into this as well. I’m a regular Github user where this just works, and this was a huge blocker where I thought I was doing something wrong.

So I’d say definitely not stale, and if you point out where in the code work on this would need to be started, it could be a good first issue? :)

[guillep2k]

@jancborchardt This has been fixed in 1.10 I believe. Probably backported to 1.9.6 as well. What's your version?

[mxmehl]

On 1.9.6 and when creating a pull request using the upstream's "Pull Request" button (e.g. https://git.fsfe.org/org/repo/compare/master...master) does not show the fork's branches, so it does not seem to be backported.

I haven't tested 1.10 yet as I would like to wait for 1.10.1 to be released. But from the changelog I cannot see an enhancement or fix that might match the issue described here, but I might be wrong

[guillep2k]

@mxmehl It was in the current 1.11.0, although the title is not very descriptive: #8670

[mxmehl]

Ah yes, that looks like it. Thanks a lot, looking forward to upgrading soon :)

[davidsvantesson]

That PR didn't really change what the poster requested. The poster wanted to see all fork branches when making new pull request in the _upstream repo_.
I am not sure if that makes sense as there can be a lot of forks.

[mxmehl]

Right, it's still not working as before.

I do not want to see all forks but only my own one + the upstream's. In 95% of the cases, the are the two sources from which a user will create pull requests.

[zeripath]

@mxmehl can you take a look at https://try.gitea.io and tell us exactly what is missing.

From the forked repo

You can see you can set the base branch to any of the original repo's branches. What we haven't done is allowed you to set the head to any of the original repo's branches or when on the original repo allow you to select the head to be one of the forked_repo's branches:

Do you mean you want these setting too?

(the best solution would be to make the repo part be lookup-able through typing a repository name instead)

[mxmehl]

My workflow is as follows:

• I have a clone of arandomer/anudderrepo here
• I click on "New pull Request" on upstream
• As "merge into", I select arandomer:master (default)
• As "pull from", I can only choose branches in the arondomer: space, not in mxmehl:

I know that I can circumvent this by:

• Typing the path manually in the address bar
• Opening the new pull request from within my fork, but then I only see branches in mxmehl:, not arandomer:.

The whole idea is that I may have a fork but also access to upstream, so "pull from" should offer both spaces.

[zeripath]

OK it's the second case then.

If you click on pull-request on your fork (mxmehl/anudderrepo) you will get the option of choosing arandomer's branches as your base.

[mxmehl]

Yes, but – excuse the strong words – IMHO this workflow is greatly unintuitive.

I am working in an organisation where the majority of Gitea users are new to Git (translators, diverse staff...), so we have to provide quite concrete documentation on how to interact with the service. Pull Requests are part of the suggested workflows, and I would assume that in such a documentation I can write "go to _this link_, press new pull request, and select your branch". With your solution, the link would always be different, and why would someone want to create a pull request on their own fork?

[zeripath]

yes I agree - I'm just looking at how to fix this.

[mxmehl]

OK, thanks! If you need user feedback, please let me know. I just am afraid that I cannot test as the large productive system I maintain is the only one I administrate currently.