show fetched commits after git pull --rebase

Question

Is there a way to see what commits have been pulled in from the remote repository after you do a git pull --rebase?

In other words: git pull will show a summary of changed files at the end (like git diff --stat). Git pull --rebase does not. How can I see this information anyway, if at all possible?

I know this is possible after a normal git pull or by doing a manual git fetch first, by comparing local & remote branches using git log master..origin/master --stat or similar, but this does not work after a git pull --rebase, unless I'm doing something wrong...

To clarify, my question is 2-part:
1) How to view diffstat (summary of changed files) after a git pull --rebase, similar to what git pull shows.
2) How to view log of all new "incoming" commits after a git pull --rebase.

Answer 1

Actually, git rebase has had this all along (well, since 1.6.something). Remember that git pull is just git fetch followed by either git merge or git rebase (as directed by various options and settings). That is, git pull does a pair of underlying git operations.

The reason it does not work after you have finished your git pull is that git pull is in fact that pair of operations, and if you just did one pair, there are probably no new changes brought in by your second git fetch, so there is nothing new to show. If you were to use your reflog history to reset items to the state they were in before the first pair of operations, the second pair of operations would have something to show.

You can (as I see VonC has already noted) get an after-the-fact report on what changed in either the upstream or your local branch using your own reflogs. But presumably you want to see this on the next git pull even if that does a rebase, and that's where a sneaky set of git defaults come in.

If you manually add --stat to your git pull line, the pull script passes this option on to either git merge or git rebase (whichever one it runs). If you leave this option out, git relies on a default option.

The default --stat option for git merge is the setting in your configuration's merge.stat, which defaults to True. The default --stat option for git rebase is the setting in your configuration's rebase.stat, which defaults to False.

Let me repeat that, because it's just peculiar and non-obvious (I only discovered this because of your question—I generally avoid git pull myself).

The default --stat option for merge is True but the default --stat option for rebase is False.

If you set the defaults yourself, you can make the stat output show up.

Alternatively, you can pass an explicit --stat to git pull.

Note that you can also set pull.rebase (to either True, meaning default to rebasing, or preserve, meaning default to rebase with --preserve as well), or branch.name.rebase (to True or preserve), to make git pull use --rebase. This is independent of whether you supply --stat as a pull argument.

---

Edit: VonC's answer is gone (at least right now) but there are bits of it in various comments. The trick to use after the fact is that when git fetch updates origin/develop, your own reflog now contains an origin/develop@{1}: your own previous value for origin/develop, before git fetch updated it. Thus, you can select the revision-set that came in with origin/develop@{1}..origin/develop. Diffing those two with --stat will get you the desired output. Note that you may, or may not depending on your particular shell, have to quote the curly braces in the @{1} part.

Answer 2

You could try (after the git pull --rebase) accessing the reflog:
(see git rev-parse SPECIFYING REVISIONS)

@\{<n>\}, e.g. @{1}

You can use the @ construct with an empty ref part to get at a reflog entry of the current branch.
For example, if you are on branch blabla then @{1} means the same as blabla@{1}.

Here origin/master@{1} would reference origin/master before the fetch (since pull = fetch + merge/rebase)

To see the fetched commits, the OP Q-BiC suggests in the comments:

git log "origin/develop@{1}"..origin/develop

That being said, torek's solution is easier, as it will take care of that step for you, with --stat being passed automatically to git fetch.