吉特警告：“主人”的登录只能追溯到约会？如何引用远程分支而不是本地分支？

Question

当我在一个工作分支中执行以下命令时(从remotes/origin/master签出)：

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?)中的评论说：“主人@正在使用reflog，这与您的本地存储库创建相关，而不是提交日期。”

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

Answer 1

TL;DR

这一行：

提交a2d1acfe855899e7e9562a16b692aa5d1f44d5dd (头->主、源/主)

指示您的master已与您的origin/master同步，因此您处于相同的提交状态。唯一要注意的是，这是你的吉特对他们的吉特的记忆，这是你的吉特最后一次和他们的吉特说话。运行git fetch origin，让您自己的Git从他们的(origin's) Git中获得任何新的信息，并更新您的origin/*名称:现在，您的Git内存已经更新了。(当然，它可能几秒钟后就过时了。)

长

吉特可能会很混乱。术语不太一致，词汇被重复使用，含义完全不同，到处都是。

在这种情况下，警告消息就是您注意到的：master@{...}使用Git所称的重触发器。reflogs是参考文献或引用的日志(与git log无关)。名称master是一个分支名称，它是一种特定的引用形式。这指的是ref refs/heads/master的reflog，而refs/heads/master是拼写master的很长一段路。

因此，我们刚刚看到了一个问题: log一词可能意味着git log，但它可能意味着其他的东西。不过，与“分支”这个词相比，这还不算什么！例如，见What exactly do we mean by "branch"?

为了帮助消除所有的混乱，让我们从一些更基本的东西开始吧。当您使用Git时，涉及的存储库不止一个。你有你的副本，我有我的，弗雷德有他的，爱丽丝有她的，等等。这些Git存储库中的每一个都有分支和提交之类的东西。我们怎么才能把它们都搞清楚呢？

在Git中，只有少数几个绝对。主要的一个是在git log输出中看到的散列is：

提交1cFER7bc5c292c09a108e0319ddcec8ab3608887

以及：

提交a2d1acfe855899e7e9562a16b692aa5d1f44d5dd

这些散列ID确实是通用的。如果您已经提交了a2d1acfe855899e7e9562a16b692aa5d1f44d5dd，那么您的Git就称它为a2d1acfe855899e7e9562a16b692aa5d1f44d5dd。如果爱丽丝有，她的吉特也叫它a2d1acfe855899e7e9562a16b692aa5d1f44d5dd。每个拥有这个提交的人，都称它为同一个丑陋的散列ID。他们要么拥有这个，要么没有任何带有那个丑陋的哈希ID的东西。

当然，只有人类才能处理这些散列ID。但大多数时候，我们不需要直接处理这些问题:我们有一台电脑。为什么不让它记住散列ID？Git就是这样做的--这就是分支名称的来源--但是每个Git存储库都有自己的分支名称。您的master不需要与鲍勃的master相匹配。您的名字master将包含一些丑陋的散列ID，但它可能与其他人的不同。

为了解决这个问题，我们有我们的Gits --记住彼此的分支。当让您的Git调用其他您称为origin的Git时，您的Git会列出它们的Git列表，列出其分支名称和散列ID。他们可能会说我的master是a2d1acfe855899e7e9562a16b692aa5d1f44d5dd。如果是这样的话，Git会确保您有提交(通过散列ID)，如果不是从他们的Git获得它，然后Git将您的refs/remotes/origin/master名称设置为a2d1acfe855899e7e9562a16b692aa5d1f44d5dd。

这最终意味着，您可以通过查看您的Git's master现在是什么，来判断Git是什么，这是Git上一次与Git交谈的时候。您可以更改您的master是哪个哈希ID；您的Git将保留您的origin/master-full名称refs/remotes/origin/master-alone，直到您再次调用Git并找出它们的master在哪里为止。

你的翻版记着，你的吉特在你的推荐信里放了些什么。每次Git更新master时，Git都会在Git's refs/heads/master reflog中存储一个新条目。这也适用于你的远程跟踪名称:每次你的Git更新你的refs/remotes/origin/master，你的origin主内存，你的Git就会在你的Git's refs/remotes/origin/master reflog中存储一个新条目。所以你可以查看你的重发，但这是为了看看你以前在你自己的参考文献中有什么。这不看任何实际的提交，至少不是马上；这些重发条目每个保存一个散列ID，你可以用它来找到提交。

刷新日志条目对每个Git都是私有的。你的Git将不会从他们的Git获得重发条目。随着时间的推移，你看不出他们对裁判做了什么，反正也看不出来。随着时间的推移，你只能看到你的裁判做了些什么。

Answer 2

@{xyz}语法检查reflogs，这些是refs所指向的日志。所有裁判都是本地的。@{2.days.ago}是“我两天前在这次回购中检出的东西”。如果你想要的是“至少在两天前，最后一件事交给了原主。”一个很好的入门工具包：

git rev-list -1 --before 2.days.ago origin/master

根据您要寻找的内容，可能还需要--first-parent和/或--author-date-order。

您也可以使用特定的日期，例如

git checkout `git rev-list -1 --before="Apr 1 2020" HEAD`