github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 10:39:38 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

link to create PR after push is missing after update from 1.8 to 1.9 on existing repos #3859

New Issue
Closed
opened 2025-11-02 05:28:36 -06:00 by GiteaMirror · 29 comments
GiteaMirror commented 2025-11-02 05:28:36 -06:00
Owner
Copy Link

Originally created by @morph027 on GitHub (Aug 28, 2019).

  • Gitea version (or commit ref): 1.9.2
  • Git version: 2.17.1
  • Operating system: Ubuntu Bionic 18.04
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

This is the server side log when pushing a branch:

Aug 28 09:18:48 gitea gitea[12311]: 2019/08/28 09:18:48 modules/ssh/ssh.go:181:func1() [E] SearchPublicKeyByContent: public key does not exist [id: 0]
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started GET /api/internal/serv/command/23/repo/test-testproject?mode=2&verb=git-receive-pack for 127.0.0.1
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed GET /api/internal/serv/command/23/repo/test-testproject?mode=2&verb=git-receive-pack 200 OK in 46.200043ms
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started GET /api/internal/hook/pre-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&gitObjectDirectory=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&gitAlternativeObjectDirectories=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects&gitQuarantinePath=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&prID=0 for 127.0.0.1
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed GET /api/internal/hook/pre-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&gitObjectDirectory=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&gitAlternativeObjectDirectories=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects&gitQuarantinePath=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&prID=0 200 OK in 15.310619ms
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started GET /api/internal/hook/post-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&username=repo for 127.0.0.1
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed GET /api/internal/hook/post-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&username=repo 200 OK in 166.081004ms
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started POST /api/internal/ssh/23/update/60351 for 127.0.0.1
Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed POST /api/internal/ssh/23/update/60351 200 OK in 21.996506ms

My local shell just gives:

git push --set-upstream origin foo
Total 0 (delta 0), reused 0 (delta 0)
To ssh://git.example.com:2222/repo/test-testproject.git
 * [new branch]      foo -> foo
Branch 'foo' set up to track remote branch 'foo' from 'origin'.

Description

Today i've managed to update Gitea from 1.8.2 to 1.9.2 and after pushing a new branch, i'm missing the remote message to create a new PR introduced in #4716

Originally created by @morph027 on GitHub (Aug 28, 2019). <!-- NOTE: If your issue is a security concern, please send an email to security@gitea.io instead of opening a public issue --> <!-- 1. Please speak English, this is the language all maintainers can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/gitea) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. --> - Gitea version (or commit ref): 1.9.2 - Git version: 2.17.1 - Operating system: Ubuntu Bionic 18.04 - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: This is the server side log when pushing a branch: ``` Aug 28 09:18:48 gitea gitea[12311]: 2019/08/28 09:18:48 modules/ssh/ssh.go:181:func1() [E] SearchPublicKeyByContent: public key does not exist [id: 0] Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started GET /api/internal/serv/command/23/repo/test-testproject?mode=2&verb=git-receive-pack for 127.0.0.1 Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed GET /api/internal/serv/command/23/repo/test-testproject?mode=2&verb=git-receive-pack 200 OK in 46.200043ms Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started GET /api/internal/hook/pre-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&gitObjectDirectory=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&gitAlternativeObjectDirectories=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects&gitQuarantinePath=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&prID=0 for 127.0.0.1 Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed GET /api/internal/hook/pre-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&gitObjectDirectory=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&gitAlternativeObjectDirectories=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects&gitQuarantinePath=%2Fsrv%2Fgitea%2Frepositories%2Frepo%2Ftest-testproject.git%2F.%2Fobjects%2Fincoming-jai1uS&prID=0 200 OK in 15.310619ms Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started GET /api/internal/hook/post-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&username=repo for 127.0.0.1 Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed GET /api/internal/hook/post-receive/repo/test-testproject?old=0000000000000000000000000000000000000000&new=e5d620284e950f7ac1fe361ab6a92ac01dd98d02&ref=refs%2Fheads%2Ffoo&userID=21&username=repo 200 OK in 166.081004ms Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Started POST /api/internal/ssh/23/update/60351 for 127.0.0.1 Aug 28 09:18:48 gitea gitea[12311]: [Macaron] 2019-08-28 09:18:48: Completed POST /api/internal/ssh/23/update/60351 200 OK in 21.996506ms ``` My local shell just gives: ``` git push --set-upstream origin foo Total 0 (delta 0), reused 0 (delta 0) To ssh://git.example.com:2222/repo/test-testproject.git * [new branch] foo -> foo Branch 'foo' set up to track remote branch 'foo' from 'origin'. ``` ## Description Today i've managed to update Gitea from 1.8.2 to 1.9.2 and after pushing a new branch, i'm missing the remote message to create a new PR introduced in #4716
GiteaMirror added the issue/staleissue/needs-feedback labels 2025-11-02 05:28:36 -06:00
GiteaMirror commented 2025-11-02 05:28:37 -06:00
Author
Owner
Copy Link

@morph027 commented on GitHub (Aug 28, 2019):

Created a new org repo, forked into my user and pushed a branch and the beloved magic link is there...will check the repo hook settings...

@morph027 commented on GitHub (Aug 28, 2019): Created a new org repo, forked into my user and pushed a branch and the beloved magic link is there...will check the repo hook settings...
GiteaMirror commented 2025-11-02 05:28:37 -06:00
Author
Owner
Copy Link

@morph027 commented on GitHub (Aug 28, 2019):

When deleting a fork of a non-working repo and creating a new fork, the link also appears after pushing a new branch.

@morph027 commented on GitHub (Aug 28, 2019): When deleting a fork of a non-working repo and creating a new fork, the link also appears after pushing a new branch.
GiteaMirror commented 2025-11-02 05:28:37 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Aug 28, 2019):

From admin settings run Resynchronize pre-receive, update and post-receive hooks of all repositories. task:
image

@lafriks commented on GitHub (Aug 28, 2019): From admin settings run `Resynchronize pre-receive, update and post-receive hooks of all repositories.` task: ![image](https://user-images.githubusercontent.com/165205/63863232-8854cb00-c9b6-11e9-899a-40bd1bf3b916.png)
GiteaMirror commented 2025-11-02 05:28:38 -06:00
Author
Owner
Copy Link

@morph027 commented on GitHub (Aug 29, 2019):

Nothing changed. Looking at the filesystem, all projects got the same hooks (the initial bash script which loops over all hooks in .d directory and the gitea hook call in .d directory).

Not sure where the hook gets lost. Will try to enable more debug output and see, if i can find something related.

@morph027 commented on GitHub (Aug 29, 2019): Nothing changed. Looking at the filesystem, all projects got the same hooks (the initial bash script which loops over all hooks in .d directory and the gitea hook call in .d directory). Not sure where the hook gets lost. Will try to enable more debug output and see, if i can find something related.
GiteaMirror commented 2025-11-02 05:28:38 -06:00
Author
Owner
Copy Link

@morph027 commented on GitHub (Sep 6, 2019):

Also weird, we still got repos which are working without re-fork (in another organisation).

@morph027 commented on GitHub (Sep 6, 2019): Also weird, we still got repos which are working without re-fork (in another organisation).
GiteaMirror commented 2025-11-02 05:28:38 -06:00
Author
Owner
Copy Link

@morph027 commented on GitHub (Sep 6, 2019):

comparing a fresh fork (user1, where it's working) against a non-working fork (user2):

gitea:/srv/gitea/repositories# diff -Naur user1/repo.git/hooks/post-receive.d/ user2/repo.git/hooks/post-receive.d/gitea 
gitea:/srv/gitea/repositories# diff -Naur user1/repo.git/hooks/post-receive.d/gitea user2/repo.git/hooks/post-receive.d/gitea

No difference.

@morph027 commented on GitHub (Sep 6, 2019): comparing a fresh fork (`user1`, where it's working) against a non-working fork (`user2`): ``` gitea:/srv/gitea/repositories# diff -Naur user1/repo.git/hooks/post-receive.d/ user2/repo.git/hooks/post-receive.d/gitea gitea:/srv/gitea/repositories# diff -Naur user1/repo.git/hooks/post-receive.d/gitea user2/repo.git/hooks/post-receive.d/gitea ``` No difference.
GiteaMirror commented 2025-11-02 05:28:39 -06:00
Author
Owner
Copy Link

@guillep2k commented on GitHub (Sep 7, 2019):

Perhaps some users are using VS2019? In my VS2019 I'm not getting the remote messages in the Source Control - Git log, but I do get them if I use git from bash.

@guillep2k commented on GitHub (Sep 7, 2019): Perhaps some users are using VS2019? In my VS2019 I'm not getting the remote messages in the `Source Control - Git` log, but I do get them if I use git from bash.
GiteaMirror commented 2025-11-02 05:28:39 -06:00
Author
Owner
Copy Link

@morph027 commented on GitHub (Sep 7, 2019):

Nayh, just using command line ;)

@morph027 commented on GitHub (Sep 7, 2019): Nayh, just using command line ;)
GiteaMirror commented 2025-11-02 05:28:39 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Sep 15, 2019):

@guillep2k the push link is more efficient than VS2019 I think. You can just click that link and create a PR in seconds.

@lunny commented on GitHub (Sep 15, 2019): @guillep2k the push link is more efficient than VS2019 I think. You can just click that link and create a PR in seconds.
GiteaMirror commented 2025-11-02 05:28:40 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Nov 14, 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 (Nov 14, 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 05:28:40 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Nov 14, 2019):

@morph027 are you sure that the hooks are even running? If your SSH key isn't managed by Gitea i.e. you can log in to the server to a shell then the hooks won't run because the environment won't get set because gitea serv won't get run.

As part of 1.11 I might pop a PR on that enforces pushes to Gitea repos have to be done in such a way that the hooks will run properly.

@zeripath commented on GitHub (Nov 14, 2019): @morph027 are you sure that the hooks are even running? If your SSH key isn't managed by Gitea i.e. you can log in to the server to a shell then the hooks won't run because the environment won't get set because gitea serv won't get run. As part of 1.11 I might pop a PR on that enforces pushes to Gitea repos have to be done in such a way that the hooks will run properly.
GiteaMirror commented 2025-11-02 05:28:40 -06:00
Author
Owner
Copy Link

@morph027 commented on GitHub (Nov 14, 2019):

The SSH key is managed through Gitea Webinterface.

@morph027 commented on GitHub (Nov 14, 2019): The SSH key is managed through Gitea Webinterface.
GiteaMirror commented 2025-11-02 05:28:40 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Nov 14, 2019):

Yeah sorry just reading your logs - I can see that the hooks are running.

OK, so does your test repository have another branch or is that the first commit - because if it is the first commit and you have no other branches it will get set as the default branch after you push it - hence no pr message.

@zeripath commented on GitHub (Nov 14, 2019): Yeah sorry just reading your logs - I can see that the hooks are running. OK, so does your test repository have another branch or is that the first commit - because if it is the first commit and you have no other branches it will get set as the default branch after you push it - hence no pr message.
GiteaMirror commented 2025-11-02 05:28:41 -06:00
Author
Owner
Copy Link

@morph027 commented on GitHub (Nov 14, 2019):

This happens on all existing projects which did have the PR message before the update...

@morph027 commented on GitHub (Nov 14, 2019): This happens on all existing projects which did have the PR message before the update...
GiteaMirror commented 2025-11-02 05:28:41 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Nov 14, 2019):

OK let's look at the logic.

The create a PR logic is in the post-receive hook and is determined by gitea hook post-receive here:

2f73fff053/cmd/hook.go (L175-L181)

I.e the result from the pushing of a branch is res["create"] = true.

That's determined by here:

2f73fff053/routers/private/hook.go (L173-L240)

The important parts are:

2f73fff053/routers/private/hook.go (L173)

I.e. you're pushing the creation of a branch not deleting it.

2f73fff053/routers/private/hook.go (L185)

I.e. the user is allowed to create PRs

2f73fff053/routers/private/hook.go (L204)

i.e. the branch being pushed to is not the default branch - this is the problem with your testcase.

2f73fff053/routers/private/hook.go (L221)

i.e. There is not already a PR for this branch

@zeripath commented on GitHub (Nov 14, 2019): OK let's look at the logic. The create a PR logic is in the post-receive hook and is determined by `gitea hook post-receive` here: https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/cmd/hook.go#L175-L181 I.e the result from the pushing of a branch is `res["create"] = true.` That's determined by here: https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L173-L240 The important parts are: https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L173 I.e. you're pushing the creation of a branch not deleting it. https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L185 I.e. the user is allowed to create PRs https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L204 i.e. the branch being pushed to is not the default branch - this is the problem with your testcase. https://github.com/go-gitea/gitea/blob/2f73fff053527b9ab66d74063868846ae8eec5c7/routers/private/hook.go#L221 i.e. There is not already a PR for this branch
GiteaMirror commented 2025-11-02 05:28:41 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Nov 14, 2019):

In 1.8 the logic was determined by:

11f6ed4f83/cmd/hook.go (L210-L248)

The important parts are:

11f6ed4f83/cmd/hook.go (L210)

  • This is the same.

11f6ed4f83/cmd/hook.go (L217)

  • This is the same

11f6ed4f83/cmd/hook.go (L226)

  • This is the same

11f6ed4f83/cmd/hook.go (L237)

  • This is the same.
@zeripath commented on GitHub (Nov 14, 2019): In 1.8 the logic was determined by: https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L210-L248 The important parts are: https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L210 * This is the same. https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L217 * This is the same https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L226 * This is the same https://github.com/go-gitea/gitea/blob/11f6ed4f8349119c8f9a5d57c43a0312365883d1/cmd/hook.go#L237 * This is the same.
GiteaMirror commented 2025-11-02 05:28:41 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Nov 14, 2019):

The only difference I can see between 1.8 and 1.9 is that your testcase will "work" in 1.8 because 1.8 will not set the default branch to be the first thing that is pushed.

@zeripath commented on GitHub (Nov 14, 2019): The only difference I can see between 1.8 and 1.9 is that your testcase will "work" in 1.8 because 1.8 will not set the default branch to be the first thing that is pushed.
GiteaMirror commented 2025-11-02 05:28:41 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Nov 14, 2019):

Are there definitely no errors in your logs? That's the only other way there could be a difference.

@zeripath commented on GitHub (Nov 14, 2019): Are there definitely no errors in your logs? That's the only other way there could be a difference.
GiteaMirror commented 2025-11-02 05:28:42 -06:00
Author
Owner
Copy Link

@morph027 commented on GitHub (Nov 14, 2019):

Any logs in particular? Should i set loglevel to trace?

@morph027 commented on GitHub (Nov 14, 2019): Any logs in particular? Should i set loglevel to trace?
GiteaMirror commented 2025-11-02 05:28:42 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Nov 14, 2019):

If you look at the code I've put up above for 1.9, all the points that would cause no output log.Error except for the case that you are pushing to the defaultBranch of a non-fork which doesn't log.

If you are pushing a non-default branch that you should either get a create the branch or visit the branch message. Compare the code between 1.8 and 1.9 I can't see how there could be a difference.

@zeripath commented on GitHub (Nov 14, 2019): If you look at the code I've put up above for 1.9, all the points that would cause no output `log.Error` except for the case that you are pushing to the defaultBranch of a non-fork which doesn't log. If you are pushing a non-default branch that you should either get a create the branch or visit the branch message. Compare the code between 1.8 and 1.9 I can't see how there could be a difference.
GiteaMirror commented 2025-11-02 05:28:42 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jan 13, 2020):

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 13, 2020): 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 05:28:42 -06:00
Author
Owner
Copy Link

@morph027 commented on GitHub (Jan 13, 2020):

Huh, already forgot about ;)

We've upgraded to 1.10.2 recently and the behaviour still exists.

@morph027 commented on GitHub (Jan 13, 2020): Huh, already forgot about ;) We've upgraded to 1.10.2 recently and the behaviour still exists.
GiteaMirror commented 2025-11-02 05:28:43 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jan 14, 2020):

Maybe it's the determination of isPullRequest allowed? As I wrote above the hook change I don't think can be the cause

@zeripath commented on GitHub (Jan 14, 2020): Maybe it's the determination of isPullRequest allowed? As I wrote above the hook change I don't think can be the cause
GiteaMirror commented 2025-11-02 05:28:43 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Mar 14, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Mar 14, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.
GiteaMirror commented 2025-11-02 05:28:43 -06:00
Author
Owner
Copy Link

@morph027 commented on GitHub (Mar 25, 2020):

Now running 1.11.3, even with PULL_REQUEST_PUSH_MESSAGE = true there's no consistent behaviour. Some forks are working, some not.

@morph027 commented on GitHub (Mar 25, 2020): Now running 1.11.3, even with `PULL_REQUEST_PUSH_MESSAGE = true` there's no consistent behaviour. Some forks are working, some not.
GiteaMirror commented 2025-11-02 05:28:43 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Mar 28, 2020):

OK can you tell me anything about the cases where this doesn't work? I'm gonna put a guess out here:

  • The cases where it doesn't work are all forks from an organisation.
  • They're limited to a particular organisation or orgs - maybe even a particular team reference in that organisation

Another question are the original forked repos are using an external issue tracker?

@zeripath commented on GitHub (Mar 28, 2020): OK can you tell me anything about the cases where this doesn't work? I'm gonna put a guess out here: * The cases where it doesn't work are all forks from an organisation. * They're limited to a particular organisation or orgs - maybe even a particular team reference in that organisation Another question are the original forked repos are using an external issue tracker?
GiteaMirror commented 2025-11-02 05:28:44 -06:00
Author
Owner
Copy Link

@morph027 commented on GitHub (Mar 30, 2020):

Hi!

Yes, both is true, all of our repos are forks of an organisation upstream and the upstreams are limited. Creating a PR through the webinterface works without problems.

At least in my case, i'm in the owners groups of the orgs.

And there are repos within the same organisation, where everything works.

None of the repos is using an external issue tracker.

@morph027 commented on GitHub (Mar 30, 2020): Hi! Yes, both is true, all of our repos are forks of an organisation upstream and the upstreams are limited. Creating a PR through the webinterface works without problems. At least in my case, i'm in the owners groups of the orgs. And there are repos within the same organisation, where everything works. None of the repos is using an external issue tracker.
GiteaMirror commented 2025-11-02 05:28:44 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (May 30, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (May 30, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.
GiteaMirror commented 2025-11-02 05:28:44 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jun 13, 2020):

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

@stale[bot] commented on GitHub (Jun 13, 2020): This issue has been automatically closed because of inactivity. You can re-open it if needed.
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 issue/needs-feedback issue/stale
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#3859
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?