Pull Request Updated by Removing Commits

[Rich Duncan]

One of my teams will periodically see an activity update in their pull requests that is something like:

  Updated pull request by removing 2 commits

This is followed by the list of commits that have been removed.  In the case that I'm looking at, the team member does not know what they did to remove the commits.

Anyone have any ideas how this might happen?

-Rich

[Jean-Serge Gagnon]

We just had this occur and I think I know why - basically what Michael said except related to pull requests and forked repos. 

We had 2 pull requests with similar source both being merged into same destination branch. The act of merging pull request #2 caused commits to be showed as removed in pull request #1 by the user who merged pull request #2.

Let me explain:

We have repos hierarchy like this:

PRODUCT repo (master branch is prod)
|-- release 1 repo (develop branch is dev work)
|-- release 2 repo (develop branch is dev work)

We routinely take commits from release 1 that went to production and merge them back into the PRODUCT repo on the master branch.

This trickles down to the release repos as no one works on the master branch there.

We then create a pull request from the master branch to our develop branch in each release repos.

What happened is the developer created their own branch to merge the production code themselves and merged those commits to the develop branch.

Which has the side effect of removing those merged commits from the other pull request.

[Michael Heemskerk]

Hi Rich,

I suspect it happened as a result of a change to the target branch. Consider this example:

  c1 --- c2 --- c3 <--- master
          \
            --- c4 <--- feature/A
                 \
                   --- c5 <-- feature/B            

In this example, master is at commit c3, feature/A is at c4 and feature/B is at c5. Suppose you have 2 pull requests:

• PR1: feature/A --> master (would add c4 to the master branch)
• PR2: feature/B --> master (would add c4 and c5 to the master branch)

When PR1 is merged, the commit graph looks like this:

  c1 --- c2 --- c3 --- c6  <--- master
          \            /
            --- c4 --- 
                 \
                   --- c5 <-- feature/B            

commit c4 is now 'on' master because it's in master's ancestry. At this point, PR2 would no longer introduce c4 on master because it's already there. Merging PR1 has changed the 'scope' of what PR2 would add to the target branch.

Note that this is not the only possible scenario. Other options are:

• one or more commits are stripped from the source branch (a push -f was done to rewind the source branch to an older commit)
• one or more commits were amended/rebased and the source branch was updated through a force-push. In this scenario, the push would simultaneously remove the old commits and add the newly amended/rebased commits. 

[Julius Davies [bit-booster.com]]

Any history rewrite will do that.  E.g.,  "git rebase" or "git commit --amend" or "git merge --squash" followed by a "git push --force".

No work is lost.  It's just that old commits are being replaced with new commits after a rebase.

Also, if you're only seeing "Updated pull request by removing 2 commits" and never seeing newer entries of "Updated pull request by adding X commit(s)", that corresponds to someone doing something like "git reset --hard HEAD~2" and "git push --force" - in other words, backing out some changes through a history rewrite.

The rebase or squash cases are the most typical for seeing activity like this.