问题标签 [git-rev-list]

我正在使用git rev-list（因为这是 GitPythoniter_commits在幕后运行的）来获取一个分支而不是另一个分支中存在的更改。

我想省略所有被精心挑选到旧分支中的提交。

这是cherry-pick之前的提交树： git log before cherry-pick

现在，我想挑选提交“6”到“release-6.6”：

这是cherry-pick后的提交树：cherry-pick 后的git log

现在我想比较分支release-6.6和分支release-6.8并只获取提交5,7,8：

输出是 4 个提交，它们是：5,6,7,8.

我什至尝试：

但它们都不起作用。

我究竟做错了什么？我怎样才能只得到提交5,7,8？

谢谢

git rev-list --pretty='%H %an <%ae> %at' origin/topic-branch ^origin/master

输出以下内容：

所需的输出应仅包含占位符包含的漂亮格式的字符串，如下所示：

我不知道如何摆脱rev-list.

我们的开发流程规定每个开发人员都应该先将他/她的主题分支变基为 master，然后将其与--no-ff标志合并，以创建合并气泡。这会产生一个漂亮且易于遵循的历史图表。但是，有时开发人员会不小心通过 GitHub 用户界面而不是通过 Git CLI 合并他们的拉取请求，Git CLI 在实际合并之前不会变基，从而导致以下“混乱”的历史图表：

如果遵循该过程，我们将看到以下历史图表：

（我正在更改提交E并C进行'初始化，因为它们会有不同的哈希值）

我们需要以编程方式获取此类损坏的合并提交的列表，例如E.

git rev-list --merges --format='%h %p' A..G | grep -v '^commit'产生以下输出：

第一列代表合并提交，第二列是第一个父级（也是合并提交），第三列是第二个父级 - 来自主题分支的提交。但是，损坏的合并的父关系似乎没问题 - 该命令在固定的 Git 历史记录（第二张图）上运行时给出相同的输出，因此我们无法识别它。

必须有另一种方法来检测项目中损坏的合并提交。请注意，不需要git在历史记录中的每个提交上执行的解决方案，因为某些项目有 50k+ 提交，并且单次git执行需要超过 2 秒。

在寻找 git hook 示例时，我遇到了以下帖子：https ://github.com/Movidone/git-hooks/blob/master/pre-receive ，我想了解以下命令：

其中 new_list 来自：

我认为 rev-list 按时间倒序显示提交。

但是，有人可以分享更多关于什么-not和-all选项的见解吗？

根据文档：

我无法完全理解这些选项。

[更新] 在做了一些测试提交后，发现如果我不使用--notand--all选项，那么git rev-list列出分支上的所有提交，而不是我打算推送的那些。

--all但是，想了解为什么在传递选项时它不在终端上打印 sha 值？

我几乎可以获得深度优先排序，git rev-list --in-commit-order --objects --reverse HEAD这给了我类似的东西

当我想要

首先将列表后处理到深度并不简单，因为两棵共同祖先的树可能共享同一个孩子

我正在尝试识别我的项目历史记录中已删除的大文件。当我这样做时，我可以看到一个有序列表。

通常，我可以从历史记录中删除文件而不会出现这样的问题：

但是，如果文件过去有不同的名称或路径，一旦我删除该文件，当我再次运行 rev-list 时，我会看到我刚刚删除的同一个文件，大小相同，但过去的不同路径或名称。

有没有办法用 rev-list 查看对象的所有文件路径，这样我就不必像这样在历史记录中迭代路径/名称更改？

Consider the following scenario:

I want to rebase the feature branch, so they appear as commits added after main, but not merge it yet. The problem is, main was already merged (not rebased) in the past and those commits are now in feature too. I want the rebase to automatically skip the commits already present in main and feature.

This is what I want:

And afterwards just merge normally with a merge commit like so

It's a bit like in this question, but I don't want to merge. Just rebase and then force push in the branch itself.
Git rebase, skip merge-commits

EDIT:
I found out that the scenario is way more complex. Consider three branches, feature1(F) feature2(G) and main(C). S stands for squash, M for merge commit.

Current situation

I want to rebase feature2 onto main but skip all commits from feature1, since they are already in main (as a squash) and also in feature2 (merged commits)

git rev-list输出文件路径的所有版本（在重命名处停止），git --follow --pretty=%h输出跨移动/重命名的所有版本，但是我如何（非手动）找到修改文件内容的最新提交（最好chmod也排除 's ）？

就我而言，我有一个文件被多次重命名，但我想在更改它的最新提交之前重新设置基准。

我正在尝试撤消过去的不良 git 做法，并且在这样做的过程中，我想获取特定文件的提交列表，比某个时间戳更新（对这些文件的较旧提交被精心挑选到主分支，考虑到原始分支还远未完成，我现在意识到这是一个非常糟糕的主意）。图解简化：

• 提交 B1..Bm 不久前从主题分支中被精心挑选到 master 中，此处显示为 CB1、CB2 等。
• 在原始主题分支中继续处理文件（主分支未触及它们），此处为 Bm+1..Bn
• 我最近创建了 topic-R 分支作为 topic 分支的副本，并在 merge-base 之上与 master 交互地重新建立它以清理历史记录（压缩和修复）。

我现在想从 topic-R 中获取提交 Bm+1..Bn 的列表git rev-list。所以我找到了提交 CBm，在 topic-R 的历史记录（和 rev-list 输出）中，它显示了我期望的日期，大约 9 个月前。

因此，我将其提供给rev-list并且令人惊讶的是，我得到了所有提交，就好像--after/--since过滤器被忽略了一样。传递--pretty给rev-list仍会在 Date 下显示预期日期- 几个月前的日期，即编写代码时的日期。但是当我传递--timestamp到时，我会看到列表中所有rev-list提交的最新时间戳——从几天前我重新设置 topic-R 分支时开始。

这里发生了什么？有没有办法告诉rev-list通过原始时间戳进行过滤，这显然仍然可用？

我知道我可以只使用 topic-R 中的 Bm+1 的哈希来限制列表，但我很好奇 git 跟踪哪些类型的时间戳以及是否可以按原始时间戳进行过滤。

假设我们在某个提交C中有一个文件F。给定未来的提交C'，推断C'中从F派生的文件列表的最佳方法是什么？

一个文件可以在从一个提交到另一个提交的过程中以任意顺序多次修改、重命名、移动、复制、删除、拆分和合并。

我想确定通过此类操作从原始文件“派生”的文件的最终列表（可以是空的），最好使用 git 的管道命令。

是的，没有办法可靠地确定文件是否被拆分、合并、移动或复制。但是在 git-log 或 git-blame 中用于相同目的的算法应该没问题。（感谢@SpaceKatt）。

TL;DR我想要一个在给定输入的情况下产生以下输出的函数：

注意：如果这是相反的问题（即查找文件的历史记录），则可以使用git-logor得出解决方案git-blame，尽管我也不知道对此有完美的解决方案（不涉及瓷器）。