Can't do PR, Gitea shows older version of files in target branch #3950

New Issue

GiteaMirror · 2025-11-02T05:31:29-06:00

GiteaMirror commented

2025-11-02 05:31:29 -06:00

Originally created by @johnchristopher on GitHub (Sep 13, 2019).

Gitea version (or commit ref): 1.9.0
Git version: 2.22.0
Operating system: https://hub.docker.com/layers/gitea/gitea/1.9.0/images/sha256-614e96d1f8150e9c1b7ea89c6d091fc905c3a1be51b283bf4946e3f80c2edb5f
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:

Description

edited for clarity

I am trying to merge a branch to master via the web interface of Gitea (pull request). I already pushed my feature branch. Master is up-to-date with my local repository.
After opening the pull request Gitea says it can't merge because some files have modifications that are in conflicts with master (fair enough).
But when comparing those files on Gitea, in the pull request UI - where I can see diff between files, I see that the content of files from master are older than the actual and current master branch. It's like Gitea is trying to merge with a different commit than the latest commit on master.

Why isn't Gitea using the latest commit of the master branch to do the merge ?

Originally created by @johnchristopher on GitHub (Sep 13, 2019). - Gitea version (or commit ref): 1.9.0 - Git version: 2.22.0 - Operating system: https://hub.docker.com/layers/gitea/gitea/1.9.0/images/sha256-614e96d1f8150e9c1b7ea89c6d091fc905c3a1be51b283bf4946e3f80c2edb5f - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [X] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [X] Not relevant - Log gist: ## Description *edited for clarity* I am trying to merge a branch to master via the web interface of Gitea (pull request). I already pushed my feature branch. Master is up-to-date with my local repository. After opening the pull request Gitea says it can't merge because some files have modifications that are in conflicts with master (fair enough). But when comparing those files on Gitea, in the pull request UI - where I can see diff between files, I see that the content of files from master are older than the actual and current master branch. It's like Gitea is trying to merge with a different commit than the latest commit on master. Why isn't Gitea using the latest commit of the master branch to do the merge ?

GiteaMirror added the issue/stale label 2025-11-02 05:31:29 -06:00

GiteaMirror closed this issue

2025-11-02 05:31:30 -06:00

GiteaMirror commented

2025-11-02 05:31:30 -06:00

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

I'm sorry if you know all this already, but you probably need to pull the latest master into the PR. If it was my setting (bash on Linux or Windows), what I do is:

$ git pull master {remote for your main repo}
$ git push {your origin} {your pr branch}

For example, I have go-gitea/gitea forked in guillep2k/gitea (both in Github). The remote for my fork is called "origin" and the remote for go-gitea/gitea (the original repository I want to make a PR to) is called "upstream":

$ git remote -v
origin  git@github.com:guillep2k/gitea.git (fetch)
origin  git@github.com:guillep2k/gitea.git (push)
upstream        git@github.com:go-gitea/gitea.git (fetch)
upstream        git@github.com:go-gitea/gitea.git (push)

Then I do:

$ git checkout my-pr-branch
$ git pull upstream master
$ git push -u origin my-pr-branch

There's a lots of ways of doing this, but perhaps this is the most easy for me to explain.

@guillep2k commented on GitHub (Sep 13, 2019): I'm sorry if you know all this already, but you probably need to pull the latest master into the PR. If it was my setting (bash on Linux or Windows), what I do is: ``` $ git pull master {remote for your main repo} $ git push {your origin} {your pr branch} ``` For example, I have go-gitea/gitea forked in guillep2k/gitea (both in Github). The remote for my fork is called "origin" and the remote for go-gitea/gitea (the original repository I want to make a PR to) is called "upstream": ``` $ git remote -v origin git@github.com:guillep2k/gitea.git (fetch) origin git@github.com:guillep2k/gitea.git (push) upstream git@github.com:go-gitea/gitea.git (fetch) upstream git@github.com:go-gitea/gitea.git (push) ``` Then I do: ``` $ git checkout my-pr-branch $ git pull upstream master $ git push -u origin my-pr-branch ``` There's a lots of ways of doing this, but perhaps this is the most easy for me to explain.

GiteaMirror commented

2025-11-02 05:31:30 -06:00

@johnchristopher commented on GitHub (Sep 13, 2019):

Not sure I was clear enough or if I misunderstand what you explained:

Master in my local repository is identical to master in remote repository (no mirror or upstream PR). PR is used in a two dev workflow where we check each other out.

I ended up merging local master into my local feature branch and then I pushed that local feature branch and then Gitea accepted to merge into master. Gitea should have been able to do the first merge online (as I have been doing for months now ?) though, right ?

If open one of the file on master (through Gitea interface) it has latest content (oc) but the content of that same file in the merge UI of Gitea is different (from some previous commit).

I edited the first post for clarity.

@johnchristopher commented on GitHub (Sep 13, 2019): Not sure I was clear enough or if I misunderstand what you explained: Master in my local repository is identical to master in remote repository (no mirror or upstream PR). PR is used in a two dev workflow where we check each other out. I ended up merging local master into my local feature branch and then I pushed that local feature branch and then Gitea accepted to merge into master. Gitea should have been able to do the first merge online (as I have been doing for months now ?) though, right ? If open one of the file on master (through Gitea interface) it has latest content (oc) but the content of that same file in the merge UI of Gitea is different (from some previous commit). I edited the first post for clarity.

GiteaMirror commented

2025-11-02 05:31:30 -06:00

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

If you're dealing with only one remote, perhaps the commit graph can be useful for you?

I mean this page:

https://try.gitea.io/gitea/gitea/graph

@guillep2k commented on GitHub (Sep 13, 2019): If you're dealing with only one remote, perhaps the commit graph can be useful for you? I mean this page: https://try.gitea.io/gitea/gitea/graph ![image](https://user-images.githubusercontent.com/18600385/64890127-45952300-d645-11e9-8882-befc0ee3fe5c.png) ![image](https://user-images.githubusercontent.com/18600385/64890159-5a71b680-d645-11e9-81ed-d54af4b57096.png) ![image](https://user-images.githubusercontent.com/18600385/64890095-301ff900-d645-11e9-8bcc-648375a85f73.png)

GiteaMirror commented

2025-11-02 05:31:30 -06:00

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

There you can check where is your branch with respect to master.

@guillep2k commented on GitHub (Sep 13, 2019): There you can check where is your branch with respect to master.

GiteaMirror commented

2025-11-02 05:31:31 -06:00

@worthy7 commented on GitHub (Oct 7, 2019):

@johnchristopher Can you recreate this on https://try.gitea.io?

@worthy7 commented on GitHub (Oct 7, 2019): @johnchristopher Can you recreate this on https://try.gitea.io?

GiteaMirror commented

2025-11-02 05:31:31 -06:00

@johnchristopher commented on GitHub (Oct 24, 2019):

@worthy7 Not at the moment. That PR and commits are now buried under a lot of commits, PR and merge. If I stumble upon this behaviour again I'll try to provide a minimal example.

@johnchristopher commented on GitHub (Oct 24, 2019): @worthy7 Not at the moment. That PR and commits are now buried under a lot of commits, PR and merge. If I stumble upon this behaviour again I'll try to provide a minimal example.

GiteaMirror commented

2025-11-02 05:31:31 -06:00

@zeripath commented on GitHub (Oct 25, 2019):

It's really helpful if you can reproduce merging problems on try. Message me @zeripath if you do and I will grab a copy of the repository to do further testing.

We would like to improve the reporting of errors and the reporting of conflicts however it's been hard to reproduce without artificially creating conflicts in a way that might not reproduce reality. If we had good examples of where we're failing it would be better.

Thanks

@zeripath commented on GitHub (Oct 25, 2019): It's really helpful if you can reproduce merging problems on try. Message me @zeripath if you do and I will grab a copy of the repository to do further testing. We would like to improve the reporting of errors and the reporting of conflicts however it's been hard to reproduce without artificially creating conflicts in a way that might not reproduce reality. If we had good examples of where we're failing it would be better. Thanks

GiteaMirror commented

2025-11-02 05:31:31 -06:00

@stale[bot] commented on GitHub (Dec 24, 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 (Dec 24, 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:31:31 -06:00

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

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

@stale[bot] commented on GitHub (Jan 7, 2020): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 12:28:00 -06:00

[PR #3950] [MERGED] Adjust z-index for floating labels (#3939) #17163

Sign in to join this conversation.