Git blame命令获取两个日期之间的列表

Question

Git 给出 since 选项

git blame --since=3.weeks -- foo

有什么方法可以让我在两次约会之间得到指责名单？
即:类似于 git log --since 和 --until 的内容。

Answer 1

similar to git log since and until

那个was discussed here in 2017 .

首先，git blame采用提供给 git rev-list 的选项, 限制 promise 被考虑到指责。

git rev-list 确实有:

-until=<date>
--before=<date>

Show commits older than a specific date.

所以这些选项没有记录在 git blame 下，而是记录在 git rev-list 下。

但是:所述选项被git blame忽略。

即，git blame --since=3.weeks --before=2.weeks -- foo 不会“出错”，但是...会默默地忽略 -- before=2.weeks 部分。

---

Junio C Hamano 评论(谈到提交，但这也适用于日期):

Many options that rev-list takes are parsed but then ignored by blame, simply because they do not make much sense in the context of the command, and "--before" is one of them.

It is interesting to realize that "--since" (and its synonym "--after") does make sense, unlike "--before" (and its synonym "--until") which does not.

Let's imagine a history like this (time flows from left to right):

--c1--c2--c4--c6--c8--c9
        \         /
         c3--c5--c7

where the tip of the history is at commit "c9", and the number in the name of each commit denotes its timestamp.

• "git rev-list c9" starts from "c9", and follows the chain of parents and would produce c9, c8, c7, c6, ..., c1, ....

• If you add "--after 2", i.e. "git rev-list --after 2 c9" does exactly the same traversal as the above, but stops following the chain of parents for commits that is earlier than the specified time.

• If you add "--before 6", i.e. "git rev-list --before 6 c9" does exactly the same traversal as the first one, but does not show the commit whose timestamp is later than the specified time.
  It would be like saying "git rev-list c5 c6" in the above topology; the traversal from c9 down to c5 and c6 is done only to find c5 and c6 to start the "real" traversal from.

Now, "--after 2" will still show "c9", the tip you start your traversal from, and this is important in the context of "blame".

Unlike "git rev-list" (and "git log" family of commands), which can take more than one positive endpoints in the history (e.g. it is perfectly sensible to ask "git log -p ^c1 c5 c6 -- myfile" in the example topology above), "git blame" must be given exactly one positive endpoint, as "git blame ^c1 c5 c6 -- myfile" would not make any sense (ask: "do we want to know about myfile in c5? or myfile in c6?").