Error - FindRecentlyPushedNewBranches, branch does not exist [repo_id: 64 name: main] #13065

@lunny commented on GitHub (May 29, 2024):

Please try to run sync branches on admin panel.

@lunny commented on GitHub (May 29, 2024): Please try to run `sync branches` on admin panel.

GiteaMirror commented

@Flagelmann commented on GitHub (May 29, 2024):

Yout mean the "Resynchronize pre-receive, update and post-receive hooks of all repositories."?

I have already tried multiple times it....nothing changed.

I also tried "Reinitialize all missing Git repositories for which records exist" under "Site Administration", nothing even with this.

I wish I will not have to rebuild the gitea instance from scratch.....so, re-import manually over 100 repositories (over 30 GB of data) and then also re-enable manually, by modifying manually each repository on database side the mirroring settings for each repo I have (as Gitea does not still have the way to backup these settings)....

@Flagelmann commented on GitHub (May 29, 2024): Yout mean the "Resynchronize pre-receive, update and post-receive hooks of all repositories."? I have already tried multiple times it....nothing changed. I also tried "Reinitialize all missing Git repositories for which records exist" under "Site Administration", nothing even with this. I wish I will not have to rebuild the gitea instance from scratch.....so, re-import manually over 100 repositories (over 30 GB of data) and then also re-enable manually, by modifying manually each repository on database side the mirroring settings for each repo I have (as Gitea does not still have the way to backup these settings)....

GiteaMirror commented

@wxiaoguang commented on GitHub (May 29, 2024):

Please try to run sync branches on admin panel.

I do not think FindRecentlyPushedNewBranches logic is right. Anything wrong in that function shouldn't block end users seeing a complete page.

@wxiaoguang commented on GitHub (May 29, 2024): > Please try to run `sync branches` on admin panel. I do not think `FindRecentlyPushedNewBranches` logic is right. Anything wrong in that function shouldn't block end users seeing a complete page.

GiteaMirror commented

@lunny commented on GitHub (May 29, 2024):

Yout mean the "Resynchronize pre-receive, update and post-receive hooks of all repositories."?

I have already tried multiple times it....nothing changed.

I also tried "Reinitialize all missing Git repositories for which records exist" under "Site Administration", nothing even with this.

I wish I will not have to rebuild the gitea instance from scratch.....so, re-import manually over 100 repositories (over 30 GB of data) and then also re-enable manually, by modifying manually each repository on database side the mirroring settings for each repo I have (as Gitea does not still have the way to backup these settings)....

No. It's Sync missed branches from git data to databases

@lunny commented on GitHub (May 29, 2024): > Yout mean the "Resynchronize pre-receive, update and post-receive hooks of all repositories."? > > I have already tried multiple times it....nothing changed. > > I also tried "Reinitialize all missing Git repositories for which records exist" under "Site Administration", nothing even with this. > > I wish I will not have to rebuild the gitea instance from scratch.....so, re-import manually over 100 repositories (over 30 GB of data) and then also re-enable manually, by modifying manually each repository on database side the mirroring settings for each repo I have (as Gitea does not still have the way to backup these settings).... No. It's `Sync missed branches from git data to databases`

GiteaMirror commented

@Flagelmann commented on GitHub (May 29, 2024):

I get, not for all repositories (fortunately), a Gitea error page with a big "500" at center page and then, just below, the message:

An error occurred:

FindRecentlyPushedNewBranches, branch does not exist [repo_id: 64 name: main]

Nothing else.

@Flagelmann commented on GitHub (May 29, 2024): I get, not for all repositories (fortunately), a Gitea error page with a big "500" at center page and then, just below, the message: ``` An error occurred: FindRecentlyPushedNewBranches, branch does not exist [repo_id: 64 name: main] ``` Nothing else.

GiteaMirror commented

@Flagelmann commented on GitHub (May 29, 2024):

Even with "Sync missed branches from git data to databases" nothing changed. It starts, but then nothing...

@Flagelmann commented on GitHub (May 29, 2024): Even with "Sync missed branches from git data to databases" nothing changed. It starts, but then nothing...

GiteaMirror commented

@lunny commented on GitHub (May 29, 2024):

I get, not for all repositories (fortunately), a Gitea error page with a big "500" at center page and then, just below, the message:
An error occurred:

FindRecentlyPushedNewBranches, branch does not exist [repo_id: 64 name: main]
Nothing else.

The sync will take some times, maybe you need to wait for a while and refresh the page again.

@lunny commented on GitHub (May 29, 2024): > I get, not for all repositories (fortunately), a Gitea error page with a big "500" at center page and then, just below, the message: > > ``` > An error occurred: > > FindRecentlyPushedNewBranches, branch does not exist [repo_id: 64 name: main] > ``` > > Nothing else. The sync will take some times, maybe you need to wait for a while and refresh the page again.

GiteaMirror commented

@wxiaoguang commented on GitHub (May 29, 2024):

As a quick fix: Ignore FindRecentlyPushedNewBranches err #31164

If you could build your own instance, you could try to apply it to 1.22 branch.

Or when the backport is done and 1.22-nightly is ready, please try 1.22 nightly.

@wxiaoguang commented on GitHub (May 29, 2024): As a quick fix: Ignore FindRecentlyPushedNewBranches err #31164 If you could build your own instance, you could try to apply it to 1.22 branch. Or when the backport is done and 1.22-nightly is ready, please try 1.22 nightly.

GiteaMirror commented

@Flagelmann commented on GitHub (May 29, 2024):

I am using snapcraft to deploy and get updates of Gitea.

May I get the nightly build with snap or do I have just to wait the next build?

@Flagelmann commented on GitHub (May 29, 2024): I am using snapcraft to deploy and get updates of Gitea. May I get the nightly build with snap or do I have just to wait the next build?

GiteaMirror commented

@yp05327 commented on GitHub (May 30, 2024):

As a quick fix it is ok, but I think the root reason is that sync branch has some problems.
The branch name is main, so it is default branch of repo 64?
Then what kind of this repo is? A fork, a mirror or a normal one?
Then why this branch can not be found in DB? During the creation of this repo, the main branch should has been insert into the DB.

@yp05327 commented on GitHub (May 30, 2024): As a quick fix it is ok, but I think the root reason is that sync branch has some problems. The branch name is `main`, so it is default branch of repo 64? Then what kind of this repo is? A fork, a mirror or a normal one? Then why this branch can not be found in DB? During the creation of this repo, the main branch should has been insert into the DB.

GiteaMirror commented

@wxiaoguang commented on GitHub (May 30, 2024):

Reopen, because the quick fix isn't complete. Need to figure out the root reason.

@wxiaoguang commented on GitHub (May 30, 2024): Reopen, because the quick fix isn't complete. Need to figure out the root reason.

GiteaMirror commented

@wxiaoguang commented on GitHub (May 30, 2024):

The root problem is that any branch could be renamed or deleted. Default branch may not exist in many cases.

So when running FindRecentlyPushedNewBranches, any non-existing branch should be ignored, but not reporting an error.

@wxiaoguang commented on GitHub (May 30, 2024): The root problem is that any branch could be renamed or deleted. Default branch may not exist in many cases. So when running `FindRecentlyPushedNewBranches`, any non-existing branch should be ignored, but not reporting an error.

GiteaMirror commented

@yp05327 commented on GitHub (May 30, 2024):

I can only image one case that the last branch (it is also the default branch) was deleted, and there's no branch in the repo, this error would happen.
If the default branch is renamed, repo.DefaultBranch should also be renamed?
If there's two or more branches, then when the default branch was deleted, the other one will be the new default branch?

@yp05327 commented on GitHub (May 30, 2024): I can only image one case that the last branch (it is also the default branch) was deleted, and there's no branch in the repo, this error would happen. If the default branch is renamed, repo.DefaultBranch should also be renamed? If there's two or more branches, then when the default branch was deleted, the other one will be the new default branch?

GiteaMirror commented

@Flagelmann commented on GitHub (May 30, 2024):

Jfyi, I have fixed the issue by issuing a simple UPDATE query against the specific repository ID in the repository table, updating the default_branch value from "main" to "master". Just after doing that now I can access the affected repository.

I will have to check all of them one by one, as not all repository are using the "master" branch, some are using "main".

Here a sample query I used:

UPDATE repository SET default_branch = 'master' WHERE id = 100;

Finally, I dunno why this happened, as just before the upgrade to the latest build I was able to use the affected repositories without issues (and they were on master branch, not main, and I checked it in the commit history); after the upgrade several repositories have been "moved" to the main branch without a reason.

Wishing that this will not happen anymore in the next builds.

Regards

@Flagelmann commented on GitHub (May 30, 2024): Jfyi, I have fixed the issue by issuing a simple UPDATE query against the specific repository ID in the repository table, updating the default_branch value from "main" to "master". Just after doing that now I can access the affected repository. I will have to check all of them one by one, as not all repository are using the "master" branch, some are using "main". Here a sample query I used: UPDATE repository SET default_branch = 'master' WHERE id = 100; Finally, I dunno why this happened, as just before the upgrade to the latest build I was able to use the affected repositories without issues (and they were on master branch, not main, and I checked it in the commit history); after the upgrade several repositories have been "moved" to the main branch without a reason. Wishing that this will not happen anymore in the next builds. Regards

GiteaMirror commented

@lunny commented on GitHub (May 30, 2024):

Maybe the algorithm of detection defulat branch when syncing branches into database are wrong. So that, all repositories with master as default branch but your default branch in app.ini is main will be wrong.

@lunny commented on GitHub (May 30, 2024): Maybe the algorithm of detection defulat branch when syncing branches into database are wrong. So that, all repositories with `master` as default branch but your default branch in app.ini is `main` will be wrong.

GiteaMirror commented

@Flagelmann commented on GitHub (May 30, 2024):

Probably, for now I have reverted manually, as it was the only way to fix this without disruptions, each repository affected from the wrong default branch to the correct one (master, most of the times).

But now I'm a bit worried about next builds/updates. :D

@Flagelmann commented on GitHub (May 30, 2024): Probably, for now I have reverted manually, as it was the only way to fix this without disruptions, each repository affected from the wrong default branch to the correct one (master, most of the times). But now I'm a bit worried about next builds/updates. :D

GiteaMirror commented

@lunny commented on GitHub (May 30, 2024):

Probably, for now I have reverted manually, as it was the only way to fix this without disruptions, each repository affected from the wrong default branch to the correct one (master, most of the times).

But now I'm a bit worried about next builds/updates. :D

You don't need to worry about next update. Syncing branches to database is a new infrastructure refactor of 1.22. It should only do increment sync after the first sync for every repository.

Can you confirm only repositories with default branch master were affected?

@lunny commented on GitHub (May 30, 2024): > Probably, for now I have reverted manually, as it was the only way to fix this without disruptions, each repository affected from the wrong default branch to the correct one (master, most of the times). > > But now I'm a bit worried about next builds/updates. :D You don't need to worry about next update. Syncing branches to database is a new infrastructure refactor of 1.22. It should only do increment sync after the first sync for every repository. Can you confirm only repositories with default branch `master` were affected?

GiteaMirror commented

@Flagelmann commented on GitHub (May 30, 2024):

No, actually there was even another repository that was not on master (still figuring out which was the previous one) but it was put on main also.

UPDATE: ok, the other repository was on "dev" as default branch name but it was also put to "main". Now reverted and I can access it again.

@Flagelmann commented on GitHub (May 30, 2024): No, actually there was even another repository that was not on master (still figuring out which was the previous one) but it was put on main also. UPDATE: ok, the other repository was on "dev" as default branch name but it was also put to "main". Now reverted and I can access it again.

GiteaMirror commented

@spiritLHLS commented on GitHub (May 30, 2024):

Jfyi, I have fixed the issue by issuing a simple UPDATE query against the specific repository ID in the repository table, updating the default_branch value from "main" to "master". Just after doing that now I can access the affected repository.

I will have to check all of them one by one, as not all repository are using the "master" branch, some are using "main".

Here a sample query I used:

UPDATE repository SET default_branch = 'master' WHERE id = 100;

Finally, I dunno why this happened, as just before the upgrade to the latest build I was able to use the affected repositories without issues (and they were on master branch, not main, and I checked it in the commit history); after the upgrade several repositories have been "moved" to the main branch without a reason.

Wishing that this will not happen anymore in the next builds.

Regards

I'm having the same problem, hopefully the next new release fixes this and does it automatically (since my gitea is mainly used for backups, there are too many affected repositories for me to have the time to detect and manually fix them all).

@spiritLHLS commented on GitHub (May 30, 2024): > Jfyi, I have fixed the issue by issuing a simple UPDATE query against the specific repository ID in the repository table, updating the default_branch value from "main" to "master". Just after doing that now I can access the affected repository. > > I will have to check all of them one by one, as not all repository are using the "master" branch, some are using "main". > > Here a sample query I used: > > UPDATE repository SET default_branch = 'master' WHERE id = 100; > > Finally, I dunno why this happened, as just before the upgrade to the latest build I was able to use the affected repositories without issues (and they were on master branch, not main, and I checked it in the commit history); after the upgrade several repositories have been "moved" to the main branch without a reason. > > Wishing that this will not happen anymore in the next builds. > > Regards I'm having the same problem, hopefully the next new release fixes this and does it automatically (since my gitea is mainly used for backups, there are too many affected repositories for me to have the time to detect and manually fix them all).

GiteaMirror commented

@Flagelmann commented on GitHub (May 30, 2024):

Well, I checked the 180+ repositories I have right now on my Gitea instance and I would say that 1/3 of them have been affected by this issue. Now I have fixed them, but obviously I will monitor after next update if this will happen again.

@Flagelmann commented on GitHub (May 30, 2024): Well, I checked the 180+ repositories I have right now on my Gitea instance and I would say that 1/3 of them have been affected by this issue. Now I have fixed them, but obviously I will monitor after next update if this will happen again.

GiteaMirror commented

@eeyrjmr commented on GitHub (May 30, 2024):

This is what I faced as well, luckily only one ...
In my case it was something a little bit low-level such that the one repo facing this appeared to have two origin/master and even cli got had a warning (gitea just 500 on the code page as it didn't have a default)

@eeyrjmr commented on GitHub (May 30, 2024): This is what I faced as well, luckily only one ... In my case it was something a little bit low-level such that the one repo facing this appeared to have two origin/master and even cli got had a warning (gitea just 500 on the code page as it didn't have a default)

GiteaMirror commented

@Flagelmann commented on GitHub (May 30, 2024):

This is what I faced as well, luckily only one ...

Lucky one :D

In my case, not a lot of repos have multi-branches, but only master, so after this sudden "mass-rename/sync" I got a lot of these repos basically unreachable due to the fact that the only existant branch, master, was "renamed" to main on DB level, so nothing could be retrieved.

@Flagelmann commented on GitHub (May 30, 2024): > This is what I faced as well, luckily only one ... Lucky one :D In my case, not a lot of repos have multi-branches, but only master, so after this sudden "mass-rename/sync" I got a lot of these repos basically unreachable due to the fact that the only existant branch, master, was "renamed" to main on DB level, so nothing could be retrieved.

GiteaMirror commented

@eeyrjmr commented on GitHub (May 30, 2024):

I wonder if it is all the same issue (from gitea perspective).
Basically gitea was unable to find the default branch (master or main) and hence a 500 page. If you append /issue to the URL you get to the other webUI of gitea and from there you can view branches etc. for me it was not showing master (only the other feature branches )

A git clone works and git remote -r would list the feature branches but I also had what appeared as two origins and git would provide a WARNING (while this was an ERROR for gitea).

If you Google around you will find this can occur with git and it tolerates it but gitea needs to be a bit more deterministic especially with the db sinking

My workaround was to create a new branch from the cli from what git considered master, remove the master branches (local and origin), push to origin, from gitea /issue page then change the default branch to the new branch and everything works. Finally rename this tmp branch to master

Obviously this is a tedious workaround to get the git repo in alignment so the question then is.. what should gitea do and what is causing these shadow branches

@eeyrjmr commented on GitHub (May 30, 2024): I wonder if it is all the same issue (from gitea perspective). Basically gitea was unable to find the default branch (master or main) and hence a 500 page. If you append /issue to the URL you get to the other webUI of gitea and from there you can view branches etc. for me it was not showing master (only the other feature branches ) A git clone works and git remote -r would list the feature branches but I also had what appeared as two origins and git would provide a WARNING (while this was an ERROR for gitea). If you Google around you will find this can occur with git and it tolerates it but gitea needs to be a bit more deterministic especially with the db sinking My workaround was to create a new branch from the cli from what git considered master, remove the master branches (local and origin), push to origin, from gitea /issue page then change the default branch to the new branch and everything works. Finally rename this tmp branch to master Obviously this is a tedious workaround to get the git repo in alignment so the question then is.. what should gitea do and what is causing these shadow branches

GiteaMirror commented

@Flagelmann commented on GitHub (May 30, 2024):

I did not know about the /issue URL part. Good to know.

Probably this is just a Gitea-side issue as I checked, in my case, and the git repos were still there untouched, but not visible.

Actually in my case it was much quicker to identify which was the wrong value on DB side and update it directly for all the affected repo IDs.

@Flagelmann commented on GitHub (May 30, 2024): I did not know about the /issue URL part. Good to know. Probably this is just a Gitea-side issue as I checked, in my case, and the git repos were still there untouched, but not visible. Actually in my case it was much quicker to identify which was the wrong value on DB side and update it directly for all the affected repo IDs.

GiteaMirror commented

@Cat7373 commented on GitHub (May 31, 2024):

I also encountered this problem, after upgrading to 1.22.0

@Cat7373 commented on GitHub (May 31, 2024): I also encountered this problem, after upgrading to 1.22.0

GiteaMirror commented

@wxiaoguang commented on GitHub (May 31, 2024):

I also encountered this problem, after upgrading to 1.22.0

Please try 1.22-nightly , and/or try to "Sync branches" from the admin dashboard panel

@wxiaoguang commented on GitHub (May 31, 2024): > I also encountered this problem, after upgrading to 1.22.0 Please try 1.22-nightly , and/or try to "Sync branches" from the admin dashboard panel

GiteaMirror commented

@yp05327 commented on GitHub (Jun 3, 2024):

Maybe this is caused by auto renaming branch name
After the renaming, the branch name in DB is not changed

But this could be fixed by sync branches. 🤔
After I sync branches, it worked.

@yp05327 commented on GitHub (Jun 3, 2024): Maybe this is caused by auto renaming branch name After the renaming, the branch name in DB is not changed ![image](https://github.com/go-gitea/gitea/assets/18380374/c2b54396-aa8d-4ca5-8f1c-b3aa7e7f4f36) But this could be fixed by sync branches. 🤔 After I sync branches, it worked.

GiteaMirror commented

@yp05327 commented on GitHub (Jun 3, 2024):

Does this related to #28056 ?
User didn't notice this issue, so branches are not synced since updated to v1.21, and errors occurred after upgrade to v1.22?

@yp05327 commented on GitHub (Jun 3, 2024): Does this related to #28056 ? User didn't notice this issue, so branches are not synced since updated to v1.21, and errors occurred after upgrade to v1.22?

GiteaMirror commented

@Flagelmann commented on GitHub (Jun 3, 2024):

Actually in my case it was not due to an auto-renaming of the branches, as I had, suddenly after the auto-upgrade (using snap image) 40-50 repositories not usable anymore using Gitea, then I fixed each of them directly in DB and after the value updated on DB side I did just an F5 on the page of the affected repo and it turned back working as expected.

Also, on https://github.com/go-gitea/gitea/issues/28056 the error was about LoadBranches while in this case I got FindRecentlyPushedNewBranches.

Obviously I tried several times the "Sync Branches" but it was completely useless (nothing fixed with that function).

@Flagelmann commented on GitHub (Jun 3, 2024): Actually in my case it was not due to an auto-renaming of the branches, as I had, suddenly after the auto-upgrade (using snap image) 40-50 repositories not usable anymore using Gitea, then I fixed each of them directly in DB and after the value updated on DB side I did just an F5 on the page of the affected repo and it turned back working as expected. Also, on https://github.com/go-gitea/gitea/issues/28056 the error was about **LoadBranches** while in this case I got **FindRecentlyPushedNewBranches**. Obviously I tried several times the "Sync Branches" but it was completely useless (nothing fixed with that function).

GiteaMirror commented

@theAkito commented on GitHub (Jun 20, 2024):

100% agree with OP. Same experience here.

@theAkito commented on GitHub (Jun 20, 2024): 100% agree with OP. Same experience here.

GiteaMirror commented

@wxiaoguang commented on GitHub (Jun 20, 2024):

100% agree with OP. Same experience here.

It has been fixed in 1.22-nightly (which will be 1.22.1 soon), please use the 1.22-nighly binary (https://dl.gitea.com/gitea/1.22-nightly/) or docker image.

@wxiaoguang commented on GitHub (Jun 20, 2024): > 100% agree with OP. Same experience here. It has been fixed in 1.22-nightly (which will be 1.22.1 soon), please use the 1.22-nighly binary (https://dl.gitea.com/gitea/1.22-nightly/) or docker image.

GiteaMirror commented

@theAkito commented on GitHub (Jun 20, 2024):

100% agree with OP. Same experience here.

It has been fixed in 1.22-nightly (which will be 1.22.1 soon), please use the 1.22-nighly binary (https://dl.gitea.com/gitea/1.22-nightly/) or docker image.

Ah, I see, I thought it would be backported into the 1.22 branch.

Is this Nightly release production ready or would it be rather advisable to wait for 1.22.1?

Is there a release date for 1.22.1?

@theAkito commented on GitHub (Jun 20, 2024): > > 100% agree with OP. Same experience here. > > It has been fixed in 1.22-nightly (which will be 1.22.1 soon), please use the 1.22-nighly binary (https://dl.gitea.com/gitea/1.22-nightly/) or docker image. > Ah, I see, I thought it would be backported into the 1.22 branch. Is this Nightly release production ready or would it be rather advisable to wait for 1.22.1? Is there a release date for 1.22.1?

GiteaMirror commented

@wxiaoguang commented on GitHub (Jun 20, 2024):

Ah, I see, I thought it would be backported into the 1.22 branch.

Yes, it has been backported to 1.22, so 1.22-nightly contains it.

Is this Nightly release production ready or would it be rather advisable to wait for 1.22.1?

Yes, because 1.22-nighty will be 1.22.1 soon. It is exactly for production so no need to wait.

Is there a release date for 1.22.1?

Maybe in a several days.

@wxiaoguang commented on GitHub (Jun 20, 2024): > Ah, I see, I thought it would be backported into the 1.22 branch. Yes, it has been backported to 1.22, so 1.22-nightly contains it. > Is this Nightly release production ready or would it be rather advisable to wait for 1.22.1? Yes, because 1.22-nighty will be 1.22.1 soon. It is exactly for production so no need to wait. > Is there a release date for 1.22.1? Maybe in a several days.

GiteaMirror commented

@theAkito commented on GitHub (Jun 20, 2024):

@wxiaoguang

Which branch or commit do I need to check out from Git to get exactly the state of 1.22-nightly? I want to build my own Docker image.

@theAkito commented on GitHub (Jun 20, 2024): @wxiaoguang Which branch or commit do I need to check out from Git to get exactly the state of `1.22-nightly`? I want to build my own Docker image.

GiteaMirror commented

@delvh commented on GitHub (Jun 20, 2024):

release/1.22

@delvh commented on GitHub (Jun 20, 2024): `release/1.22`

GiteaMirror commented

@delvh commented on GitHub (Jun 20, 2024):

(± one day as nightly is probably built only once a day as the name implies)

@delvh commented on GitHub (Jun 20, 2024): (± one day as `nightly` is probably built only once a day as the name implies)

GiteaMirror commented

@theAkito commented on GitHub (Jun 20, 2024):

Nice, seems to work now and the issue is worked around. Thank you!

@theAkito commented on GitHub (Jun 20, 2024): Nice, seems to work now and the issue is worked around. Thank you!

GiteaMirror commented

@delvh commented on GitHub (Jun 23, 2024):

The issue seems to be fixed.

@delvh commented on GitHub (Jun 23, 2024): The issue seems to be fixed.

GiteaMirror commented

@yp05327 commented on GitHub (Jun 23, 2024):

The root reason is not fixed.
We have some unknown issues about sync branch to DB.

@yp05327 commented on GitHub (Jun 23, 2024): The root reason is not fixed. We have some unknown issues about sync branch to DB.

GiteaMirror commented

@theAkito commented on GitHub (Jun 24, 2024):

@yp05327 I agree.

I even specifically said

the issue is worked around

because it is not fixed. 😄

@theAkito commented on GitHub (Jun 24, 2024): @yp05327 I agree. I even specifically said > the issue is worked around because it is *not* fixed. 😄

GiteaMirror commented

@wxiaoguang commented on GitHub (Jun 24, 2024):

I believe the root problem needs a new issue to clarify the details, but not keeping discussing "FindRecentlyPushedNewBranches" here .....

The FindRecentlyPushedNewBranches bug is indeed fixed, it sounds like a workaround but the approach is right: to make the system robust. No matter there is the root problem or not, the fix is still right and necessary.

(And see my comment above: https://github.com/go-gitea/gitea/issues/31163#issuecomment-2138581805 the default branch may not exist in some cases)

@wxiaoguang commented on GitHub (Jun 24, 2024): I believe the root problem needs a new issue to clarify the details, but not keeping discussing "FindRecentlyPushedNewBranches" here ..... The FindRecentlyPushedNewBranches bug is indeed fixed, it sounds like a workaround but the approach is right: to make the system robust. No matter there is the root problem or not, the fix is still right and necessary. (And see my comment above: https://github.com/go-gitea/gitea/issues/31163#issuecomment-2138581805 the default branch may not exist in some cases)

GiteaMirror commented