git warning : Log for 'master' only goes back to a date? 如何引用远程分支而不是本地分支？

Question

当我在工作分支中执行以下命令时(今天从 remotes/origin/master check out ):

git checkout master
git diff --name-status "@{2 days ago}" "@{now}"

它说:

warning: Log for 'HEAD' only goes back to Thu, 19 Sep 2019 16:01:05 -0700.

然而，当我检查 git log master ，它显然可以追溯到更远的地方:

commit a2d1acfe855899e7e9562a16b692aa5d1f44d5dd (HEAD -> master, origin/master)
Merge: 1cfee7bc5 14583d879
Author: ABC
Date:   Wed Sep 18 14:05:51 2019 -0700

    Merge-Request: 2457 from 'CXSFA-44175' into 'master'

commit 1cfee7bc5c292c09a108e0319ddcec8ab3608887
Merge: 8ab7bc71e 80464ea73
Author: DEF
Date:   Wed Sep 18 10:03:04 2019 -0700

安德鲁在这个问题( git: Log for 'master' only goes back to date bug? )中的评论说:
“master@ 正在使用 reflog，它与您的本地存储库创建相关，而不是提交日期”

但是，我想不出这个问题的解决方案。
我只想从远程主分支而不是我的本地工作副本获取日志。

Answer 1

TL; 博士

这一行:

commit a2d1acfe855899e7e9562a16b692aa5d1f44d5dd (HEAD -> master, origin/master)

表示您的 master已经与您的 origin/master 同步，所以你在同一个提交上。一个警告是，这是来自您的 Git 对他们的 Git 的内存，这是您的 Git 与他们的 Git 对话的最后一次。运行 git fetch origin任何时候让你自己的 Git 从他们的( origin 的)Git 中获取任何新的东西并更新你的 origin/*名称:现在您的 Git 内存是最新的。 (当然，它可能会在几秒钟后过时。)

长

Git 可能非常令人困惑。术语不是很一致，单词被重复使用，含义完全不同，到处都是。

在这种情况下，警告消息正是您注意到的: master@{...}使用 Git 所说的引用日志。引用日志是引用或引用的日志(与 git log 无关)。名称 master是一个分支名称，它是一种特定的引用形式。所以这指的是 ref refs/heads/master 的 reflog , 和 refs/heads/master很长的路要拼出来 master .

所以我们刚刚看到了一个问题:log 这个词可能意味着 git log ，但它可能意味着别的东西。不过，与分支这个词相比，这算不了什么!参见，例如， What exactly do we mean by "branch"?

不过，为了帮助消除所有混淆，让我们从更基本的东西开始。当您使用 Git 时，涉及的存储库不止一个。你有你的，我有我的，Fred 有他的，Alice 有她的，等等。这些 Git 存储库中的每一个都有分支和提交之类的东西。我们怎样才能让它们保持正直？

在 Git 中只有几个绝对值。主要的是您在 git log 中看到的那些哈希 ID。输出:

commit 1cfee7bc5c292c09a108e0319ddcec8ab3608887

和:

commit a2d1acfe855899e7e9562a16b692aa5d1f44d5dd

这些哈希 ID 是真正通用的。如果你有提交 a2d1acfe855899e7e9562a16b692aa5d1f44d5dd ，你的 Git 称它为 a2d1acfe855899e7e9562a16b692aa5d1f44d5dd .如果 Alice 拥有它，她的 Git 会调用它 a2d1acfe855899e7e9562a16b692aa5d1f44d5dd也。每个提交的人都称其为相同的大而丑陋的哈希 ID。他们要么有那个，要么没有那个大而丑陋的哈希ID。

当然，单纯的人类在处理这些哈希 ID 方面是很糟糕的。但是大多数时候我们不必直接处理它们:我们有一台计算机。为什么不让它记住哈希 ID？所以 Git 会这样做——这是分支名称的来源——但每个 Git 存储库都有自己的分支名称。您的 master不需要匹配 Bob 的 master .您的姓名 master将持有一些丑陋的大哈希 ID，但它可能与其他人的不同。

为了解决这个问题，我们让 Git 记住彼此的分支。当你的 Git 调用其他一些你称之为 origin 的 Git 时，你的 Git 有他们的 Git 列出它的分支名称和哈希 ID。他们的 Git 可能会说我的 master是 a2d1acfe855899e7e9562a16b692aa5d1f44d5dd .如果是这样，你的 Git 会确保你有那个提交(通过哈希 ID)，如果没有，从他们的 Git 中获取它，然后你的 Git 设置你的 refs/remotes/origin/master姓名至 a2d1acfe855899e7e9562a16b692aa5d1f44d5dd .

这最终意味着你可以分辨出他们的 Git 是什么 master是，最后一次你的 Git 与他们的 Git 交谈，通过检查你的 Git 的 origin/master就是现在。您可以更改您的 master 的哈希 ID是;你的 Git 会离开你的 origin/master —全名 refs/remotes/origin/master — 独自一人，直到你的 Git 再次调用他们的 Git 并找出他们的位置 master是。

你的 reflog 会记住你的 Git 在你的引用中的内容。每次你的 Git 更新你的 master ，您的 Git 将在您的 Git 的 refs/heads/master 中存储一个新条目引用。这也适用于您的远程跟踪名称:每次您的 Git 更新您的 refs/remotes/origin/master ，你的内存 origin的主人，您的 Git 在您的 Git 的 refs/remotes/origin/master 中存储了一个新条目引用。所以你可以查看你的 reflogs，但那是为了看看你过去在你自己的 refs 中有什么。这不考虑任何实际提交，至少不是立即提交；这些 reflog 条目每个都包含一个哈希 ID，您可以使用它来查找提交。

Reflog 条目对于每个 Git 都是私有(private)的。你的 Git 不会从他们的 Git 获得 reflog 条目。随着时间的推移，你无法看到他们对他们的裁判做了什么，反正不是这样。你只能看到你的 Git 随着时间的推移对你的引用做了什么。