search

backstrokeapp / server

:swimmer: A Github bot to keep repository forks up to date with their upstream.
https://backstroke.co
MIT License
667 stars 62 forks source link

Stop creating empty pull requests #60

Closed evandrocoan closed 7 years ago

evandrocoan commented 7 years ago

On the repository:

  1. https://github.com/evandrocoan/sublime_indent_and_braces/pull/4

It is always creating a empty pull request every time I ran the update link:

curl -X POST https://backstroke.us/_dfasdf1asd1f3dsf32df.....

I had been pushed a commit it that repository in past, and now it is coming back with my pull request merge into that repository:

image

image

1egoman commented 7 years ago

@evandrocoan Taking a look at this merged pr, the pull request proposes the correct changes to your repository (the only change in the upstream Epskampie:master that isn't in evandrocoan:master is the merge commit 81a8ab3, which is the only commit in the pull request, as expected.) When you click merge, Github creates an empty merge commit--f4dc758-- and never actually adds the commit 81a8ab3 to the history of evendrocoan:master.

I'm not really sure what's going on here, but Backstroke is creating the pull request correctly. I think you should attempt to try to bring the fork up to date with the master on the command line and/or open a support ticket with Github as this seems to be a bug in pull requests.

evandrocoan commented 7 years ago

There is no way to solve the repeated merge by GitHub:

When you merge a Pull Request into a branch using a merge commit, it generates a new Commit SHA.

When you compare two branches, it looks for the last common ancestor between the two branches and the differences will include all changes that were introduced after this commit.

Even though both branches have the same changes implemented, the compare will still show those differences, because the changes were committed into each branch via a different commit SHA.

This is expected behavior currently. We would normally recommend rebasing master onto your fork branch after changes have been merged, in order to keep both in sync with each other.

I'm afraid a rebase and merge using the UI would also generate different commit SHA's. The rebase would have to be performed locally.

I can understand the frustrations with this one but it isn't currently possible to completely sync two branches without changing the commit SHA's when merging from a Pull Request.

For the next time, one way to manage branches between forks is to delete the branch that you merged into the parent repository after merging the Pull Request.

You can then recreate a new branch which is based off of the new parent branch and continue working from there.