github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-13 19:37:47 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

[Bug] Unable to modify or delete PDF files trough pull requests #5162

New Issue
Closed
opened 2025-11-02 06:16:27 -06:00 by GiteaMirror · 18 comments
GiteaMirror commented 2025-11-02 06:16:27 -06:00
Owner
Copy Link

Originally created by @ghost on GitHub (Apr 1, 2020).

  • Gitea version (or commit ref): tested with 1.11.3 and 1.12 (dev)
  • Git version: 2.26.0
  • Operating system: tested in Windows 10 and Windows Server 2016
  • Database:
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

Description

I’ve created a new repository. In the master branch of this repository there is a single pdf file. I’ve set branch protection for master as follows:

Enable branch protection.
Disable push.
Enable a white list for pull request with a single user.
Establish required approvals to 1.

Then I create a new branch and modify the pdf file. After commit/push the branch, I create a pull request to merge my changes into master, but I get the following error:

“This pull request has changes conflicting with the target branch. sample.pdf”

This is a test repository and nobody has modified this pdf in another branch. Furthermore, my local git doesn’t find any conflicts between these two branches.

The same occurs if I open a new branch and delete the PDF file. When I open the pull request to push changes into master, I get the same error.

In both cases, if I modify the master branch protection, I can push changes to master without any conflicts.

Originally created by @ghost on GitHub (Apr 1, 2020). - Gitea version (or commit ref): tested with 1.11.3 and 1.12 (dev) - Git version: 2.26.0 - Operating system: tested in Windows 10 and Windows Server 2016 - Database: - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: ## Description I’ve created a new repository. In the master branch of this repository there is a single pdf file. I’ve set branch protection for master as follows: Enable branch protection. Disable push. Enable a white list for pull request with a single user. Establish required approvals to 1. Then I create a new branch and modify the pdf file. After commit/push the branch, I create a pull request to merge my changes into master, but I get the following error: “This pull request has changes conflicting with the target branch. sample.pdf” This is a test repository and nobody has modified this pdf in another branch. Furthermore, my local git doesn’t find any conflicts between these two branches. The same occurs if I open a new branch and delete the PDF file. When I open the pull request to push changes into master, I get the same error. In both cases, if I modify the master branch protection, I can push changes to master without any conflicts.
GiteaMirror added the issue/confirmedtype/bugissue/workaround labels 2025-11-02 06:16:27 -06:00
GiteaMirror commented 2025-11-02 06:16:28 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jul 26, 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 (Jul 26, 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 06:16:29 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 27, 2020):

Still happens with version 1.12.1. Any updates on this issue?

@ghost commented on GitHub (Jul 27, 2020): Still happens with version 1.12.1. Any updates on this issue?
GiteaMirror commented 2025-11-02 06:16:29 -06:00
Author
Owner
Copy Link

@liwei-2020 commented on GitHub (Sep 19, 2020):

@ndgracia
I am new with Gitea, and I just encountered the same problem, not only with pdf files but with Word (docx) files as well. Could you test with a Word document and see if it is the same?

I am using Gitea 1.12.3 running on Windows server 2019.

To my surprise, there were no follow-ups on this topic since you submitted the issue. Are we the only people having this problem? Or perhaps it only happens with Windows operating system?

@liwei-2020 commented on GitHub (Sep 19, 2020): @ndgracia I am new with Gitea, and I just encountered the same problem, not only with pdf files but with Word (docx) files as well. Could you test with a Word document and see if it is the same? I am using Gitea 1.12.3 running on Windows server 2019. To my surprise, there were no follow-ups on this topic since you submitted the issue. Are we the only people having this problem? Or perhaps it only happens with Windows operating system?
GiteaMirror commented 2025-11-02 06:16:29 -06:00
Author
Owner
Copy Link

@mjkwak commented on GitHub (Sep 19, 2020):

I can confirm this happens with word files also, windows server as SO.

@mjkwak commented on GitHub (Sep 19, 2020): I can confirm this happens with word files also, windows server as SO.
GiteaMirror commented 2025-11-02 06:16:29 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 6, 2020):

I have several queries about this... Does the user running gitea have a .gitconfig set? Similarly what is your user's .gitconfig and server's?

It would be helpful to get some logs when this happens - we'll need RUN_MODE=dev and some extensive logs:

[log]
MODE      = console
LEVEL     = debug
REDIRECT_MACARON_LOG=true
MACARON=console
ROUTER=console
XORM=console
@zeripath commented on GitHub (Oct 6, 2020): I have several queries about this... Does the user running gitea have a .gitconfig set? Similarly what is your user's .gitconfig and server's? It would be helpful to get some logs when this happens - we'll need `RUN_MODE=dev` and some extensive logs: ```ini [log] MODE = console LEVEL = debug REDIRECT_MACARON_LOG=true MACARON=console ROUTER=console XORM=console ```
GiteaMirror commented 2025-11-02 06:16:29 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Oct 13, 2020):

Hi @zeripath,

In our demo server, the system .gitconfig file is:

[core]
	symlinks = false
	autocrlf = false
[color]
	diff = auto
	status = auto
	branch = auto
	interactive = true
[help]
	format = html
[rebase]
	autosquash = true

The user that's running Gitea has the following .gitconfig configuration:

[http]
	sslVerify = false
[gui]
	recentrepo = ...
[user]
	name = Gitea
	email = gitea@fake.local
[core]
	quotepath = false
	commitGraph = true
	longpaths = true
[gc]
	writeCommitGraph = true

And my local user's gitconfig is:

[user]
	name = ...
	email = ...
[credential]
	helper = manager
[core]
	autocrlf = true

Also, I attach the log files generated in dev mode. Please, let me know if you need anything else.
log.zip

@ghost commented on GitHub (Oct 13, 2020): Hi @zeripath, In our demo server, the system .gitconfig file is: ``` [core] symlinks = false autocrlf = false [color] diff = auto status = auto branch = auto interactive = true [help] format = html [rebase] autosquash = true ``` The user that's running Gitea has the following .gitconfig configuration: ``` [http] sslVerify = false [gui] recentrepo = ... [user] name = Gitea email = gitea@fake.local [core] quotepath = false commitGraph = true longpaths = true [gc] writeCommitGraph = true ``` And my local user's gitconfig is: ``` [user] name = ... email = ... [credential] helper = manager [core] autocrlf = true ``` Also, I attach the log files generated in dev mode. Please, let me know if you need anything else. [log.zip](https://github.com/go-gitea/gitea/files/5369812/log.zip)
GiteaMirror commented 2025-11-02 06:16:29 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 13, 2020):

Hi!

Those logs unfortunately aren't particularly insightful.

If I had to guess the problem will be the autocrlf meaning your local git is fixing the problem automatically for you.

What we'd need to do is to figure out what is causing the conflict. We'd need to copy some of the things gitea does to check things.

Gitea checks for conflicts here: dfa7291f8f/services/pull/patch.go (L52)

If there are conflicts then those are reported.

Now - this is not perfect and there are ways in which git when it does its merges can resolve merge conflicts - but we don't have a working copy to check out and ensure that the merges match so we can't do that.

The answer for most times that Gitea reports a conflict but your own git can't is to merge the base back into the head and then look again - that will resolve the conflict and Gitea should then work.

@zeripath commented on GitHub (Oct 13, 2020): Hi! Those logs unfortunately aren't particularly insightful. If I had to guess the problem will be the autocrlf meaning your local git is fixing the problem automatically for you. What we'd need to do is to figure out what is causing the conflict. We'd need to copy some of the things gitea does to check things. Gitea checks for conflicts here: https://github.com/go-gitea/gitea/blob/dfa7291f8fafd2aac032ef73a78b588e4d0e9a36/services/pull/patch.go#L52 * It first creates a temporary repo on the system that has the object directories of both the head and the base repo (https://github.com/go-gitea/gitea/blob/dfa7291f8fafd2aac032ef73a78b588e4d0e9a36/services/pull/temp_repo.go#L21) * It finds the merge-base between the head and the base. * It creates a plain diff-patch from the head to the merge-base: https://github.com/go-gitea/gitea/blob/dfa7291f8fafd2aac032ef73a78b588e4d0e9a36/services/pull/patch.go#L101 * It reads the base in to the index of the temporary repo (https://github.com/go-gitea/gitea/blob/dfa7291f8fafd2aac032ef73a78b588e4d0e9a36/services/pull/patch.go#L139) * Then it tries to apply that patch to the base If there are conflicts then those are reported. Now - this is not perfect and there are ways in which git when it does its merges can resolve merge conflicts - but we don't have a working copy to check out and ensure that the merges match so we can't do that. The answer for most times that Gitea reports a conflict but your own git can't is to merge the base back into the head and then look again - that will resolve the conflict and Gitea should then work.
GiteaMirror commented 2025-11-02 06:16:29 -06:00
Author
Owner
Copy Link

@mjkwak commented on GitHub (Oct 15, 2020):

Sorry, I don't understand it. I just create a new branch from master, modified the file, commit and push to the branch and then create the PR => The conflict appears.
True, it only happens with "binary" files, but I really cannot see why a rebase is needed or how it should resolve the conflict.

@mjkwak commented on GitHub (Oct 15, 2020): Sorry, I don't understand it. I just create a new branch from master, modified the file, commit and push to the branch and then create the PR => The conflict appears. True, it only happens with "binary" files, but I really cannot see why a rebase is needed or how it should resolve the conflict.
GiteaMirror commented 2025-11-02 06:16:30 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 17, 2020):

If we are to figure this out and fix it we will need one of the two following things:

  • Either: Compile and test gitea with some additional patches - which I am happy to write in order to test this and replicate the issue and figure out what is going on.
  • Or: Replicate the git commands that gitea does on the server to test why it is getting a conflict.

I don't run windows and therefore cannot debug this process. You will have to help me to do that.

@zeripath commented on GitHub (Oct 17, 2020): If we are to figure this out and fix it we will need one of the two following things: * Either: Compile and test gitea with some additional patches - which I am happy to write in order to test this and replicate the issue and figure out what is going on. * Or: Replicate the git commands that gitea does on the server to test why it is getting a conflict. I don't run windows and therefore cannot debug this process. You will have to help me to do that.
GiteaMirror commented 2025-11-02 06:16:30 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Oct 19, 2020):

Hi @zeripath,
Both options are OK for me. If you send me a patch I'll be glad to test it in my testing server or, if you prefer, you can tell me the exact list of commands that Gitea is using and I can try to run them in our current instance and see what happens.

@ghost commented on GitHub (Oct 19, 2020): Hi @zeripath, Both options are OK for me. If you send me a patch I'll be glad to test it in my testing server or, if you prefer, you can tell me the exact list of commands that Gitea is using and I can try to run them in our current instance and see what happens.
GiteaMirror commented 2025-11-02 06:16:30 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Oct 23, 2020):

Sorry of course you offer to help and then I immediately disappear.

OK, I tried to give the gist of what happens above: https://github.com/go-gitea/gitea/issues/10913#issuecomment-708018505

Setting RUN_MODE=dev in the app.ini will cause git to log its commands.

@zeripath commented on GitHub (Oct 23, 2020): Sorry of course you offer to help and then I immediately disappear. OK, I tried to give the gist of what happens above: https://github.com/go-gitea/gitea/issues/10913#issuecomment-708018505 Setting `RUN_MODE=dev` in the app.ini will cause git to log its commands.
GiteaMirror commented 2025-11-02 06:16:30 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Oct 27, 2020):

Hi again!

I've set RUN_MODE=dev to enable git logging and I can follow these steps until the differences in the file that was modified are shown, but after that I've reached this git command, which is referencing a path that does not exist (I assume it has been already deleted, as it seems to be a temporary file):

[git-module] [path...]\GITEA\data\tmp\local-repo\pull.git750210771: C:\Program Files\Git\cmd\git.exe -c credential.helper= -c protocol.version=2 -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= apply --check --cached C:\Users\user_name\AppData\Local\Temp\patch244594710

I have no clue about the exact commands executed to generate this patch, and I cannot see them logged with the rest of git commands. Unfortunately, this seems to be the step that is causing the conflict.

@ghost commented on GitHub (Oct 27, 2020): Hi again! I've set `RUN_MODE=dev` to enable git logging and I can follow these steps until the differences in the file that was modified are shown, but after that I've reached this git command, which is referencing a path that does not exist (I assume it has been already deleted, as it seems to be a temporary file): [git-module] [path...]\GITEA\data\tmp\local-repo\pull.git750210771: C:\Program Files\Git\cmd\git.exe -c credential.helper= -c protocol.version=2 -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= apply --check --cached C:\Users\user_name\AppData\Local\Temp\patch244594710 I have no clue about the exact commands executed to generate this patch, and I cannot see them logged with the rest of git commands. Unfortunately, this seems to be the step that is causing the conflict.
GiteaMirror commented 2025-11-02 06:16:31 -06:00
Author
Owner
Copy Link

@ThorstenWagnerSEW commented on GitHub (Nov 13, 2020):

Hi,

we encouter the same problem with .docx files. I tested 1.12.4, 1.12.5 and 1.13 rc2. If there is more information needed for debugging just let me know.

Just some idea: Is it possible that windows in the background accessed the file? I realized that you actually get a dif, even though it is a "binary" file (docx is a zipped xml I think).

Important Update: It seems that it is not related to binary files. I just testet it with some dll and everything is working fine. Maybe the idea I just posted is heading in the right direction. Maybe some preview function is responsible for the observed behaviour?

Update 2: Is this maybe related to #10268 ?

Update 3: I found the reason and some not so nice workaround:
It seems that the diff, i.e. the astextplain, has something to do with it. I edited the gitattributes file in c:\Program Files\Git\etc\ and removed the entry for the pdf files (*.pdf diff=astextplain). After this Gitea did not show the diff for the pdf anymore but the pullrequest and merge worked fine afterwards.

@ThorstenWagnerSEW commented on GitHub (Nov 13, 2020): Hi, we encouter the same problem with .docx files. I tested 1.12.4, 1.12.5 and 1.13 rc2. If there is more information needed for debugging just let me know. Just some idea: Is it possible that windows in the background accessed the file? I realized that you actually get a dif, even though it is a "binary" file (docx is a zipped xml I think). **Important Update:** It seems that it is **not related to binary files**. I just testet it with some dll and everything is working fine. Maybe the idea I just posted is heading in the right direction. Maybe some preview function is responsible for the observed behaviour? Update 2: Is this maybe related to #10268 ? Update 3: I found the reason and some not so nice workaround: It seems that the diff, i.e. the astextplain, has something to do with it. I edited the gitattributes file in c:\Program Files\Git\etc\ and removed the entry for the pdf files (*.pdf diff=astextplain). After this Gitea did not show the diff for the pdf anymore but the pullrequest and merge worked fine afterwards.
GiteaMirror commented 2025-11-02 06:16:31 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Nov 19, 2020):

Hi,

we encouter the same problem with .docx files. I tested 1.12.4, 1.12.5 and 1.13 rc2. If there is more information needed for debugging just let me know.

Just some idea: Is it possible that windows in the background accessed the file? I realized that you actually get a dif, even though it is a "binary" file (docx is a zipped xml I think).

Important Update: It seems that it is not related to binary files. I just testet it with some dll and everything is working fine. Maybe the idea I just posted is heading in the right direction. Maybe some preview function is responsible for the observed behaviour?

Update 2: Is this maybe related to #10268 ?

Update 3: I found the reason and some not so nice workaround:
It seems that the diff, i.e. the astextplain, has something to do with it. I edited the gitattributes file in c:\Program Files\Git\etc\ and removed the entry for the pdf files (*.pdf diff=astextplain). After this Gitea did not show the diff for the pdf anymore but the pullrequest and merge worked fine afterwards.

I've just tested this workaround and it worked for us as well.

@ghost commented on GitHub (Nov 19, 2020): > > > Hi, > > we encouter the same problem with .docx files. I tested 1.12.4, 1.12.5 and 1.13 rc2. If there is more information needed for debugging just let me know. > > Just some idea: Is it possible that windows in the background accessed the file? I realized that you actually get a dif, even though it is a "binary" file (docx is a zipped xml I think). > > **Important Update:** It seems that it is **not related to binary files**. I just testet it with some dll and everything is working fine. Maybe the idea I just posted is heading in the right direction. Maybe some preview function is responsible for the observed behaviour? > > Update 2: Is this maybe related to #10268 ? > > Update 3: I found the reason and some not so nice workaround: > It seems that the diff, i.e. the astextplain, has something to do with it. I edited the gitattributes file in c:\Program Files\Git\etc\ and removed the entry for the pdf files (*.pdf diff=astextplain). After this Gitea did not show the diff for the pdf anymore but the pullrequest and merge worked fine afterwards. I've just tested this workaround and it worked for us as well.
GiteaMirror commented 2025-11-02 06:16:31 -06:00
Author
Owner
Copy Link

@radnvlad commented on GitHub (Sep 28, 2021):

Just wanted to let you know that we had the same issues and the workaround above works just fine.

@radnvlad commented on GitHub (Sep 28, 2021): Just wanted to let you know that we had the same issues and the workaround above works just fine.
GiteaMirror commented 2025-11-02 06:16:32 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jul 4, 2022):

If I understand correctly, the workaround is: remove the *.pdf diff=astextplain in C:\Program Files\Git\etc\gitattributes for Windows users? This problem seems Windows-only?

@wxiaoguang commented on GitHub (Jul 4, 2022): If I understand correctly, the workaround is: remove the `*.pdf diff=astextplain` in `C:\Program Files\Git\etc\gitattributes` for Windows users? This problem seems Windows-only?
GiteaMirror commented 2025-11-02 06:16:32 -06:00
Author
Owner
Copy Link

@radnvlad commented on GitHub (Jul 4, 2022):

@wxiaoguang you need to change that on the server itself, not on the individual users machine. It is confirmed by me on windows, and this post: https://stackoverflow.com/questions/28146244/what-is-the-difference-between-diff-and-diff-astextplain says that astexplain is actually a shell script specific to msysGit, so you probably won't have that on Linux. It's the way the diff tool explains the difference on the server side that causes the problem.

@radnvlad commented on GitHub (Jul 4, 2022): @wxiaoguang you need to change that on the server itself, not on the individual users machine. It is confirmed by me on windows, and this post: https://stackoverflow.com/questions/28146244/what-is-the-difference-between-diff-and-diff-astextplain says that astexplain is actually a shell script specific to msysGit, so you probably won't have that on Linux. It's the way the diff tool explains the difference on the server side that causes the problem.
GiteaMirror commented 2025-11-02 06:16:32 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jul 8, 2025):

We have stopped Gitea's git from reading the system git config ( Make Gitea always use its internal config, ignore /etc/gitconfig #33076 ), so the system gitconfig won't affect the merge behavior now.

@wxiaoguang commented on GitHub (Jul 8, 2025): We have stopped Gitea's git from reading the system git config ( Make Gitea always use its internal config, ignore /etc/gitconfig #33076 ), so the system gitconfig won't affect the merge behavior now.
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/confirmed issue/workaround type/bug
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#5162
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?