What commits will be removed when changing the base branch of a pull request on Github?

A collaborator has created a pull request on a Github repository, which is based on the master branch. I would like to merge this into the next release branch that I am currently working on (2.0.3) instead of the master branch. As several answers point out, I can do this by clicking 'Edit' next to the pull request title and then changing the base branch.

However, when I do this, I receive a warning "Some commits from the old base branch may be removed from the timeline." The Github help page also says that "When you change the base branch of your pull request, some commits may be removed from the timeline."

Can anyone explain which commits this warning is referring to, and when they might be removed? Are these commits in the master branch, the pull request, or the new base branch (2.0.3)? And does "removed from the timeline" refer just to the discussion page for the pull request on Github, or does it mean deleting commits from the repository?

Update

As @RomainValeri pointed out, this process doesn't add or remove any commits from the repository, it just changes the commits that are shown in the pull request, since some of them may no longer fall between the base of the branch and the tip. However, the tip will still be the same same final state as before.

In my case, the pull request (feature) branched off master after my request, like this:

A---B---C---D <<< master
     \       \
      \       E---F <<< feature (pull request)
       \
        G---H <<< 2.0.3

So when I changed the base of the pull request from master to 2.0.3, it now reported that the pull request included commits C, D, E and F instead of just E and F. However I didn't want C and D in the pull request, so I first merged master into 2.0.3. That gave this:

A---B---C---D ---<<< master
     \       \    \
      \       \    E---F <<< feature (pull request)
       \       \
        G---H---I <<< 2.0.3

Then when I changed the base of feature to 2.0.3, it still just showed E and F in the pull request (the extra code beyond I), which was what I wanted.

I think in cases where feature branches off master before 2.0.3, you would see some commits disappear from the pull request if you change the base for feature to 2.0.3 (the commits between the original bases of the two branches, which are already in 2.0.3). But no commits would actually be lost from the repository.

Solution

I'm not a github user, rather bitbucket, but git concepts at work here are the same, and if I'm not mistaken, here's what it means :

Let's take a look at the example situation below

A---B---C <<< master
     \
      D---E---F <<< feature-1
           \
            G---H <<< feature-2

Here, a feature2 > master pull request would feature 4 commits : D, E, G and H.

If now you edit the pull request to have feature-1 as the base branch, your updated feature-2 > feature-1 pull request will list only G, and H.

Thus when you refresh your pull request page, D and E have been removed from the pull request scope. But there's no way a pull request would remove a commit from anywhere, this is an "additive" operation, it only creates new data.

The warning, ironically, somehow triggers what it tries to prevent : people freaking out about having lost their commits as they suddenly don't see them any more in the list. Github wanted to tell you "your commits will only be removed from the list of changes, not from your repo."