This is because the maintainer of the upstream repo squashed your first pull request into a new commit, while you continued development on the "unsquashed branch". Open your repo history (e.g. with gitk) and read on.
The initial situation was like this:
* 970f363 (your repo) Add spec for #smart_listing <-- last commit in your first pull request
* 098fcfe Add specs for #smart_listing_create
(more of your commits)
* 721817f Ignore some files
* 89e24b6 (upstream repo) Add missing update_list event <-- tip of origin/master back then
* a084fb9 Fix handling unlimited per page
(...)
ljachymczyk squashed all of your commits into one new commit before adding it to the upstream repo:
* 61cad2d (upstream repo) Feature spec <-- your work squashed into single commit
| * 970f363 (your repo) Add spec for #smart_listing <-- last commit in your first pull request
| * 098fcfe Add specs for #smart_listing_create
| (...)
| * 721817f Ignore some files
|/
* 89e24b6 Add missing update_list event
* a084fb9 Fix handling unlimited per page
(...)
Now, you must understand that Git doesn't see any connection between the single new commit (61cad2d
) and your whole branch (721817f..970f363
). Even if that single commit introduces the same changes as previous 20+ commits, for Git these are unrelated changes. (And for good reasons.)
Then you continued working in your repo, adding new commits to that old branch:
* 61cad2d (upstream repo) Feature spec
| * 0b14747 (your repo) Refactor #smart_listing_create <-- your new stuff
| * e49c522 Use the controller name by default
| * a1c1a92 Remove the spec directory in dummy app
| * 4128104 Remove gems from Gemfile and add it in gemspec
| * 970f363 Add spec for #smart_listing <-- your old stuff
| * 098fcfe Add specs for #smart_listing_create
| (...)
| * 721817f Ignore some files
|/
* 89e24b6 Add missing update_list event
* a084fb9 Fix handling unlimited per page
(...)
As you can see, all these old commits are still not present in the upstream repo - that's why they show up in the pull request. Neither merging, nor "normal" rebasing will change that.
Your new commits should have been created on top of 61cad2d
(the squashed commit), not on top of the old branch. Thus, now you need to transplant them there. This is easy assuming that the single squashed commit (61cad2d) is exactly equivalent to your old branch (i.e. git diff 970f363 61cad2d
doesn't show any changes). In that case, simply do
git branch newstuff 0b14747
git rebase --onto 61cad2d 970f363 newstuff
and you should get a newstuff
branch with four new commits based on top of the squashed commit.
Note that if 970f363
and 61cad2d
are not equivalent, you may have to solve merge conflicts. This would be an illustration of how rebasing and squashing published commits causes problems.