在git pull--rebase之后显示获取的提交

是否有一种方法可以查看在执行git pull--rebase后从远程存储库中拉入了哪些提交

换句话说：

git pull

将在末尾显示已更改文件的摘要（如

git diff--stat

）<代码>Git pull--重设基址不会。如果可能的话，我怎样才能看到这些信息

我知道，在正常的

git拉取之后，或者通过使用
git log master..origin/master--stat
或类似工具比较本地和远程分支，首先手动执行
git抓取
，这是可能的，但在
git拉取--rebase
之后，这不起作用，除非我做错了什么

为了澄清，我的问题分为两部分：

1） 如何在
git pull--rebase
之后查看diffstat（已更改文件的摘要），类似于
git pull
显示的内容。

2） 如何查看git pull--rebase之后所有新“传入”提交的日志，您可以尝试（在git pull--rebase之后）访问：

（见附件）

也就是说，'s更容易，因为它将为您完成这一步，
--stat
自动传递给
git fetch
，实际上，
git rebase
一直都有这个功能（从1.6.开始）。请记住，
git pull
只是
git fetch
，后跟
git merge
或
git rebase
（根据各种选项和设置的指示）。也就是说，
git pull
执行一对底层git操作

在您完成
git pull
之后，它不起作用的原因是
git pull
实际上是一对操作，如果您只做了一对，那么第二次
git fetch
可能不会带来新的更改，因此没有什么新的内容可显示。如果要使用reflog历史记录将项目重置为第一对操作之前的状态，则第二对操作将显示一些内容

您可以（如我所见）使用您自己的回流日志获取关于上游或本地分支的事后报告。但是，假设您希望在下一次的
git pull
中看到这一点，即使这样做了
rebase
，这就是一组狡猾的git默认值的来源

如果手动将
--stat
添加到
git pull
行，则
pull
脚本会将此选项传递到
git merge
或
git rebase
（无论运行哪一个）。如果不使用此选项，git将依赖默认选项

git merge
的默认
--stat
选项是配置的
merge.stat
，中的设置，默认为True。
git-rebase
的默认
--stat
选项是配置的
rebase.stat
，中的设置，默认为False

让我重复一遍，因为这很奇怪也不明显（我之所以发现这一点，是因为你的问题——我通常避免使用git pull）

用于
合并
的默认
--stat
选项为
True
，而
重设基础
的默认
--stat
选项为
False

如果您自己设置默认值，则可以显示stat输出

或者，您可以将显式的
--stat
传递给
git pull

请注意，您还可以设置
pull.rebase
（设置为
True
，表示默认为重定基址，或
preserve
，表示默认为使用
--preserve
重定基址），或
branch.name.rebase
（设置为
True
或
preserve
），以使
git-pull
使用
--rebase
。这与是否将
--stat
作为
pull
参数提供无关


编辑：VonC的答案不见了（至少现在是这样），但在各种评论中都有一些。事后使用的技巧是，当
git fetch
更新
origin/develope
时，您自己的reflog现在包含一个
origin/develope{1}
：在
git fetch
更新它之前，您自己先前的
origin/develope
值。因此，您可以选择随
origin/develope@{1}..origin/develope
一起提供的修订集。用
--stat
对这两个变量进行微分将得到所需的输出。请注意，您可能需要引用
@{1}
部分中的花括号，也可能不需要引用，具体取决于您的特定外壳。
如果您将
主控盘
重定基址为
原点/主控盘
，则范围
主控盘..原点/主控盘
将为空；因此，
git log master..origin/master--stat
不输出任何内容是正常的。此外，
git diff--stat master{1}
（在
git pull--rebase
之后）不就是这样吗？我不得不在“develope{1}”周围加上引号，否则它会去掉大括号并失败，但是是的，这显示了与“git pull”或“git pull--rebase--stat”相同的输出（参见torek的答案）！我不知道“{1}”是什么意思，但是….
develope{1}
的意思是“在上次移动之前，develope
指向哪里”；请看下面的内容。如果torek的答案完全解决了你的问题，考虑接受它。我删除了我的答案，因为任何Git log x.y- STAT都不起作用。@ VonC，实际上，你的答案，加上Jubobs的回答将我引入@ { 1 }符号，我可能已经找到了我的问题的第2部分的解决方案。事实上，您的
git日志头..ORIG_HEAD
或其他方法并不能满足我的要求，但是
git log“origin/develope@{1}”。origin/develope
可以！仅输出来自源代码的新提交：-）是
@{}
的同义词，与
HEAD@{}
？@Jubobs是，因为git 1.8.5+（）：
@\{<n>\}, e.g. @{1}

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