Cannot merge Pullrequest with commits but without changes #3296

New Issue

GiteaMirror · 2025-11-02T05:06:59-06:00

GiteaMirror commented

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

Originally created by @jambalaja9 on GitHub (May 7, 2019).

Gitea version (or commit ref): 1.6.1 (but also on try.gitea.io with 1.9.0+dev-215-g9139f35ff)
Git version: 2.18.0
Operating system: SUSE Linux 12.4
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (https://try.gitea.io/test4gitea/Testrepo/pulls/1)
- No
- Not relevant
Log gist:

Description

This error always occurs while fixing a mergeconflict on a protected branch.

In the Example:
The protected branch is "master" for continuous development.
We release some software from the "hotfix"-branch. (also protected)
To fix bugs we use feature-branches and merge these with pullrequests into "master" and "hotfix".

There are constellations that changes for "hotfix" should not come into "master".
But we want to merge the feature-branch into both protected-branches, that other developers don't see these commits when merging their own pullrequest.

When mergeconflicts occur, we merge "master" into the feature-branch.
So we are merging the protected-branch "master" into the feature-branch "feature_for_master" to solve the mergeconflicts or undo the changes manually.

After that the pullrequest shows some commits (done in the feature-branches), but there are no changes left to bring into "master".
Now gitea doesn't allow to merge the pullrequest due to a mergeconflict.

Screenshots

Originally created by @jambalaja9 on GitHub (May 7, 2019). - Gitea version (or commit ref): 1.6.1 (but also on try.gitea.io with 1.9.0+dev-215-g9139f35ff) - Git version: 2.18.0 - Operating system: SUSE Linux 12.4 - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (https://try.gitea.io/test4gitea/Testrepo/pulls/1) - [ ] No - [ ] Not relevant - Log gist: ## Description This error always occurs while fixing a mergeconflict on a protected branch. In the Example: The protected branch is "master" for continuous development. We release some software from the "hotfix"-branch. (also protected) To fix bugs we use feature-branches and merge these with pullrequests into "master" and "hotfix". There are constellations that changes for "hotfix" should not come into "master". But we want to merge the feature-branch into both protected-branches, that other developers don't see these commits when merging their own pullrequest. When mergeconflicts occur, we merge "master" into the feature-branch. So we are merging the protected-branch "master" into the feature-branch "feature_for_master" to solve the mergeconflicts or undo the changes manually. After that the pullrequest shows some commits (done in the feature-branches), but there are no changes left to bring into "master". Now gitea doesn't allow to merge the pullrequest due to a mergeconflict. ## Screenshots ![image](https://user-images.githubusercontent.com/13997358/57282463-6523aa00-70ad-11e9-8f21-dd1acd016fad.png)

GiteaMirror added the type/enhancement label 2025-11-02 05:06:59 -06:00

GiteaMirror closed this issue

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

GiteaMirror commented

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

@lafriks commented on GitHub (May 7, 2019):

Why would you want to merge PR with no actual changes?

@lafriks commented on GitHub (May 7, 2019): Why would you want to merge PR with no actual changes?

GiteaMirror commented

2025-11-02 05:07:01 -06:00

@jambalaja9 commented on GitHub (May 7, 2019):

Hi lafriks,
if i don't merge the PR into master my changes for hotfix will be merged into master with the next PR of another developer.

hotfix: this ist the productive softwareversion
master: this code will be used for the next release

Usually we create a feature-branch from "hotfix", fix a bug for "hotfix" on this feature-branch and merge it into "hotfix" and into "master". In this case the changes should not come into "master". If we don't merge into "master" the next developer will get my commit in his feature-branch and will merge it into "master".

@jambalaja9 commented on GitHub (May 7, 2019): Hi lafriks, if i don't merge the PR into master my changes for hotfix will be merged into master with the next PR of another developer. hotfix: this ist the productive softwareversion master: this code will be used for the next release Usually we create a feature-branch from "hotfix", fix a bug for "hotfix" on this feature-branch and merge it into "hotfix" and into "master". In this case the changes should not come into "master". If we don't merge into "master" the next developer will get my commit in his feature-branch and will merge it into "master".

GiteaMirror commented

2025-11-02 05:07:01 -06:00

@saitho commented on GitHub (May 23, 2019):

Having no changes means that both master and the pull request are the same. So there is no need to merge the branches, as merging would do nothing. ;)

However I do agree that the note that there are merge conflicts is a bit misleading when there are no actual changes that can be merged. Maybe we should fix that message.

@saitho commented on GitHub (May 23, 2019): Having no changes means that both master and the pull request are the same. So there is no need to merge the branches, as merging would do nothing. ;) However I do agree that the note that there are merge conflicts is a bit misleading when there are no actual changes that can be merged. Maybe we should fix that message.

GiteaMirror commented

2025-11-02 05:07:01 -06:00

@jambalaja9 commented on GitHub (May 24, 2019):

Yes, I agree. There will no changes be done. But "master" still doesn't know about the commits done for the "hotfix" and undone in the feature-branch for "master".
So, if another developer starts a feature-branch from "hotfix", he will bring my commits into "master" when he creates a PR from his feature-branch into "master".
To prevent that, the first PR without real changes should be merged.

@jambalaja9 commented on GitHub (May 24, 2019): Yes, I agree. There will no changes be done. But "master" still doesn't know about the commits done for the "hotfix" and undone in the feature-branch for "master". So, if another developer starts a feature-branch from "hotfix", he will bring my commits into "master" when he creates a PR from his feature-branch into "master". To prevent that, the first PR without real changes should be merged.

GiteaMirror commented

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

@stale[bot] commented on GitHub (Aug 5, 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 (Aug 5, 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:07:02 -06:00

@saitho commented on GitHub (Aug 12, 2019):

To prevent that, the first PR without real changes should be merged.

Stumbled upon the same issue right now.

Earlier I said:

Having no changes means that both master and the pull request are the same.

Which is incorrect. Even merges that do not contain changes should be merged in order to avoid having diverging branches because commits are missing in others.

@saitho commented on GitHub (Aug 12, 2019): > To prevent that, the first PR without real changes should be merged. Stumbled upon the same issue right now. Earlier I said: > Having no changes means that both master and the pull request are the same. Which is incorrect. Even merges that do not contain changes should be merged in order to avoid having diverging branches because commits are missing in others.

GiteaMirror commented

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

@jambalaja9 commented on GitHub (Aug 20, 2019):

That's the point. ;)

Even merges that do not contain changes should be merged in order to avoid having diverging branches because commits are missing in others.

@jambalaja9 commented on GitHub (Aug 20, 2019): That's the point. ;) > Even merges that do not contain changes should be merged in order to avoid having diverging branches because commits are missing in others.

GiteaMirror commented

2025-11-02 05:07:03 -06:00

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

I wonder does github or gitlab allow merging such PR?

@lafriks commented on GitHub (Aug 20, 2019): I wonder does github or gitlab allow merging such PR?

GiteaMirror commented

2025-11-02 05:07:04 -06:00

@jambalaja9 commented on GitHub (Aug 20, 2019):

Bitbucket does. But i'm not sure if github or gitlab allows it.

@jambalaja9 commented on GitHub (Aug 20, 2019): Bitbucket does. But i'm not sure if github or gitlab allows it.

GiteaMirror commented

2025-11-02 05:07:04 -06:00

@typeless commented on GitHub (Aug 20, 2019):

The stderr logged from git apply is unrecognized input.
I guess it's due to an empty patch file. Maybe we can skip the git apply check if the patch file is empty?

Edit: I can confirm from the integration test that the patch file is indeed empty.

@typeless commented on GitHub (Aug 20, 2019): The stderr logged from `git apply` is `unrecognized input`. I guess it's due to an empty patch file. Maybe we can skip the `git apply` check if the patch file is empty? Edit: I can confirm from the integration test that the patch file is indeed empty.

GiteaMirror referenced this issue

2025-11-02 12:20:57 -06:00

[PR #3296] [MERGED] Fixed asterisk based tasklist items #3295 #16868

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3296