git log反向，然后将结果限制为一 [英] git log reverse and then limit the results to one

问题描述

我在master上的提交中，我需要到达下一个提交wrt origin/master的提交.

I am at the commit on master, and I need to get to the next commit wrt origin/master.

git log --ancestry-path --date-order --reverse HEAD..origin/master

或类似的git rev-list命令为我提供了正确的提交，正确地将其撤消，因此我可以|head -n 1并使用它来完成.

or a similar git rev-list command gives me the right commits, properly reversed, so I could |head -n 1 that and be done with it.

但是，我想知道是否有可能仅使用一个进程(一次git调用)就可以得到它.首先使用-1进行限制，然后反转列表，这不是我所需要的.

However, I wonder it it's possible to get it by using just one process (one git invokation). Limiting with -1 limits first, and then reverses the list, which I not what I need.

如何做到这一点?

我知道DAG是什么，我也知道足够的图论来理解-1为何如此.我要问的不是理论问题，而是软件开发中使用的工具的问题.

I know what a DAG is, I also know enough graph theory to understand why -1 behaves like that. What I'm asking here is not a matter of theory, it's a matter of using a tool used in software development.

推荐答案

我有90％的信心，由于两个原因，无法在单个Git调用中完成此操作.

I'm 90% confident this can't be done in a single Git invocation for two reasons.

1. 看起来好像他们没有实现它.提交指向他们的父母而不是他们的孩子的指针，这就是为什么--max-count(-1)和--skip(我也曾尝试过)运行在--reverse之前的原因.由于Git是否可以在--reverse中进行打印，因此在技术上似乎应该在此之后运行-1是可行的，但是可能有一个根本原因，那就是它不是.或者，也许他们考虑了这一点，并决定任何人都可以像您一样--reverse | head -n 1.

1. It just doesn't look like they've implemented it. Commits have pointers to their parents, not their children, which is why --max-count (-1) and --skip (which I also tried a bit) run before --reverse. Since Git's capable of printing in --reverse or not, it seems like running -1 afterwards should be technically feasible, but perhaps there's an underlying reason it's not. Or perhaps they considered it and decided anyone could just --reverse | head -n 1 like you're doing.

更重要的是，即使使用--ancestry-path，也不能保证下一次提交是唯一的，因此选择--reverse -1是不明确的.这是 git-log文档中--ancestry-path描述中的示例，其中您的HEAD可以提交E.如果您对--date-order感到满意，那更多是学术问题，但是Git的DAG性质使整个下一次提交"概念变得不合理.

More importantly, you're not guaranteed a unique next commit, even when using --ancestry-path, so picking --reverse -1 is ambiguous. Here's an example from the --ancestry-path description in the git-log docs, where your HEAD could be commit E. If you're happy with --date-order, it's more of an academic issue, but the DAG nature of Git makes the whole "next commit" concept unsound.

作为一个示例用例，请考虑以下提交历史记录:

As an example use case, consider the following commit history:

    D---E-------F
   /     \       \
  B---C---G---H---I---J
 /                     \
A-------K---------------L--M

常规D..M计算作为M祖先的提交集合，但不包括作为D祖先的提交集合.这对于了解自D以来导致M的历史发生了什么是很有用的. "M有什么在D中不存在".此示例中的结果将是除A和B(当然还有D本身)之外的所有提交.

A regular D..M computes the set of commits that are ancestors of M, but excludes the ones that are ancestors of D. This is useful to see what happened to the history leading to M since D, in the sense that "what does M have that did not exist in D". The result in this example would be all the commits, except A and B (and D itself, of course).

当我们想找出M中的哪些提交被D引入的错误所污染并且需要修复时，我们可能只想查看D..M的子集，这些子集实际上是D的后代，即不包括C和K.这正是--ancestry-path选项的作用.应用于D..M范围，结果为:

When we want to find out what commits in M are contaminated with the bug introduced by D and need fixing, however, we might want to view only the subset of D..M that are actually descendants of D, i.e. excluding C and K. This is exactly what the --ancestry-path option does. Applied to the D..M range, it results in:

E-------F
 \       \
  G---H---I---J
               \
                L--M

这篇关于git log反向，然后将结果限制为一的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！