git rebase --preserve-merges的更快方法 [英] A faster way to `git rebase --preserve-merges`

查看：128 发布时间：2021/5/10 20:47:54 git merge rebase

本文介绍了git rebase --preserve-merges的更快方法的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我使用git来创建一系列功能分支，并在使用 git merge --no-ff 完成后将它们合并到母版中.这将创建空的合并提交，这对于标识先前要素分支的起点和终点很有用.

为了处理多个并发分支，甚至嵌套分支，我使用了rebase.我再也不会合并，我总是根据最新的提交重新建立分支，测试并最终在完成后与-no-ff 合并.对于嵌套分支，我会这样做:将多个分支顺序合并到主分支上，而主分支本身最终将合并到master.

为了保留有关与嵌套分支合并的信息，我经常使用 git rebase --preserve-merges .这正是我想要的，我的工作流程也没有问题.

我对git的主要问题是 git rebase --preserve-merges 非常慢(有时每次提交大约需要2秒).阅读 git的"rebase --preserve"究竟有什么用-合并"这样做(以及为什么?)我意识到git必须执行很多工作来保留合并，因为git必须在任意图上工作.

我想知道的是:由于我的工作流程产生的结果几乎等同于线性历史记录，因此有一种方法可以更快地执行 git rebase --preserve-merge 等效项鉴于我保证只有空的合并提交才可以保证历史的线性"?只要最终结果是正确的，我都不介意使用脚本或奇怪的命令.

  A-B-C/\(1)-------- D--大师\\ --- F ----- I--功能\/\/GA-B-C E G-H///\/\(2)-------- D --- F ----- I功能掌握

tl;dr::在知道基本历史是线性的情况下，如何将(1)转换为(2)，因此 git rebase --preserve-merges 不需要做太多的工作就可以了快吗?

解决方案

我对git的主要问题是 git rebase --preserve-merges 非常慢

考虑到Git 2.20+包括对"rebase"的重写，这可能不会那么慢.C.
中的机械没有更多的shell脚本.(请清楚:从Git 2.22开始，2019年第二季度，旧的重设脚本不再存在了)

请参见提交ac7f467 ， commit 55071ea (2018年8月6日)由 Pratik Karki( prertik ).
^(由 Junio C Hamano合并- gitster -在提交5ae5084 ，2018年11月2日)

变基:开始将其实现为内置

此提交模仿了用于将 difftool 转换为内置函数的策略.
我们首先将shell脚本 git-rebase.sh 重命名为 git-legacy-rebase.sh ，然后引入一个 builtin/rebase.c 只需执行shell脚本版本，除非配置设置 rebase.useBuiltin 设置为 true .
其背后的动机是重写上述 rebase.c 中的shell脚本版本，一一对应，通过配置可以方便地测试新功能 rebase.useBuiltin .
在原始的 difftool 转换中，如果 sane_execvp()试图运行以非负状态返回的旧脚本版本，命令默默地退出，没有做任何成功的事情，但是 sane_execvp()的第一个不应返回非负状态位置，因此我们使用 die()注意到这种异常情况.
我们有意避免直接阅读配置以避免当我们需要回退到 GIT _ * 环境变量时exec()编写Shell脚本.

请参见提交62c2393 ，ÆvarArnfjörðBjarmason( avar ).
^{(由 Junio C Hamano合并- gitster -在提交4520c23 ，2018年11月18日)}

文档现在状态:

  rebase.useBuiltin:

设置为 false 以在 git rebase 时使用旧版shellscript实现.
默认情况下为 true ，这意味着在C中使用对其的内置重写.
C重写最初包含在Git 2.20版中.
此选项提供了逃生功能，可以在任何情况下重新启用旧版本在重写中发现错误.
此选项和Shellscript版本 git-rebase 将在将来的某些版本中删除.
如果您发现一次性将测试选项设置为 false 的其他原因，则应将行为差异报告为git中的错误.

使用Git 2.21(2019年2月)时，" git rebase --merge "通过重新使用用于" git rebase -i "的内部机制来重新实现.

请参见提交68aa495 ，提交7b76ac6 ，提交899b49c ，提交5400677 ，提交72ee673 ， Elijah Newren( newren).
^{(由 Junio C Hamano合并- gitster -在提交8fe9c3f ，2019年2月7日)}

rebase :通过交互机制实现-合并

作为不断努力以使基础具有更统一的行为的一部分，请通过在后端之上重新实现，将合并后端的行为修改为类似于交互式后端.
交互式重载是根据cherry-pick而非内置的递归合并实现的，但是cherry-pick默认情况下也调用递归合并机制，并且可以接受特殊的合并策略和/或特殊的策略选项.>因此，确实不需要同时使用 git-rebase--merge 和 git-rebase--interactive 不再.
删除 git-rebase--merge.sh ，然后在 builtin/rebase.c 中实现.

rebase :定义线性化顺序并强制执行

有关性能，请参见提交c91c944 .

此外，仍然是Git 2.21(2019年2月):" git rebase --merge "通过重新使用用于" git rebase -i "的内部机制来重新实现.

请参见提交29d03f8 (2019年2月14日)，由 Junio C Hamano合并- gitster -在提交6f07c7b ，2019年2月14日)

rebase:通过交互式机器实现--merge

作为不断努力以使基础具有更统一的行为的一部分，请通过在后端之上重新实现，将合并后端的行为修改为类似于交互式后端.
交互式重载是根据Cherry-pick而非内置递归合并实现的，但是Cherry-pick也调用了递归合并机制默认情况下，可以接受特殊的合并策略和/或特殊的策略选项.
因此，确实不需要同时使用 git-rebase--merge 和 git-rebase--interactive 不再.
删除 git-rebase--merge.sh ，然后在 builtin/rebase.c 中实现.
这会导致一些故意但很小的用户可见更改:
修改进度输出(例如，请参阅t3406和t3420)
现在解决了一些已知的测试失败(请参阅t3421)
重新设置基础时
重击提示-合并现在是 REBASE-i ，而不是 REBASE-m .
原因:该提示反映了正在使用的后端；这使用户可以使用适当的后端信息向git邮件列表报告问题，并允许高级用户执行以下操作:知道在哪里搜索相关的控制文件.(请参阅t9903)

因为" git rebase --preserve-merge "通过重新使用用于" git rebase -i "的内部机制而重新实现的此Git 2.22(2019年第二季度)补丁很有趣:

请参见提交460bc3c ，提交0ea0847 ，提交73fdc53 ，提交7d3488e ，提交c44c246 ，提交6023c92 ，提交28dc09d ，提交fc4a673 (2019年3月19日)通过 Phillip Wood( phillipwood ).
^{(由 Junio C Hamano合并- gitster -在提交7ba06bc ，2019年5月13日)}

rebase -i :运行时不会分叉 rebase --interactive

当内置rebase启动交互式rebase时，它将解析选项，然后将其重新打包并分叉 rebase--interactive .
将 cmd_rebase__interactive()中的选项解析与业务逻辑分开，以允许通过直接调用 run_rebase_interactive()来运行交互式基础，而无需派生 rebase__interactive .
在不进行分叉的情况下启动交互式rebase使其易于调试音序器，无需担心会附着在孩子身上流程.
Ævar还报告说，某些基准性能测试的速度提高了30％.
此修补程序还可以轻松删除其中的 cmd_rebase__interactive() git-legacy-rebase.sh 和 git-rebase--preserve-merges.sh 退休的未来.

如答案开头所述:

Git 2.22(2019年4月)已经淘汰了旧的 git rebase 脚本.
参见提交d03ebd4 (2019年3月18日)通过 Junio C Hamano合并- gitster -在提交4f3036c ，2019年4月16日)
Git 2.23(2019年第三季度)完成清理工作，并指出 git rebase 唯一剩余的脚本化部分是提交082ef75 ，d4fe60e ，提交b2b9a23 ， Junio C Hamano合并- gitster -在提交ed7f8ac ，2019年6月13日)

" git rebase -i "(和朋友)过去不必要地检查要重新设置基础的分支的尖端，已通过Git 2.26(2020年第一季度)进行了更正，

请参见提交767a9c4 (2020年1月24日)，由.
^(由 Junio C Hamano合并- gitster -在提交d8b8d59 ，2020年2月14日)

rebase -i :停止检查要重新建立分支的尖端
^{报告人:SZEDERGábor}
^{签名人:阿尔本·格鲁因(Alban Gruin)}

使用基于音序器的基准库时要做的第一件事(即 rebase -i ， rebase -r 或 rebase -m )来创建待办事项列表.
这需要了解要重新确定的提交范围.
要获取范围的最后一次提交的oid，请使用 prepare_branch_to_be_rebased()检出要重新设置基准的分支的尖端，然后读取头部的oid.
此后，甚至不修改分支的尖端.另一方面，"am"后端不签出分支.
在大型存储库上，这会降低性能:使用 rebase -i'，当git静默提取分支时，用户可能必须等待编辑待办事项列表，而"quiet"才能执行.重新设置的速度将比 am'慢.
由于我们已经在 opts-> orig_head 中有了分支尖端的oid，因此切换到此提交毫无用处.
这将删除对 do_interactive_rebase()中的 prepare_branch_to_be_rebased()的调用，并将 orig_head'参数添加到 get_revision_ranges()`./p>
prepare_branch_to_be_rebased()已删除，因为它不再使用.
这引入了一个明显的变化:由于我们没有打开要重新设置基准的分支的尖端，因此在重新基准的开头不会为其创建引用日志条目.
在 linux.git 上执行的不科学的性能测量如下:
在此补丁之前:
  $ time git rebase -m --onto v4.18 463fa44eec2fef50〜463fa44eec2fef50真正的0m8,940s用户0m6,830ssys 0m2,121s 
此修补程序之后:
  $ time git rebase -m --onto v4.18 463fa44eec2fef50〜463fa44eec2fef50真实0m1,834s用户0m0,916ssys 0m0,206s 

如Git 2.26(第1季度2020)中所述，" git rebase "我已经学会了默认使用合并后端(即驱动" rebase -i "的机器)，同时允许"-apply "选项以使用"应用"后端(例如，道德上等同于"格式补丁通过管道传递给am ")的对象.

rebase.backend 配置变量可以设置为自定义.

请参见提交10cdb9f ，提交8295ed6 ，提交76340c8 ，提交c2417d3 ，提交6d04ce7 ，提交8af14f0 ，提交be50c93 ，，提交93122c9 ，提交8a997ed ，提交e98c426 ，提交d48e5e2 (2020年2月15日)和提交a9ae8fd ， Elijah Newren(<代码> newren ).
^{(由 Junio C Hamano合并- gitster -在提交8c22bd9 ，2020年3月2日)}

rebase :重命名两个主要的rebase后端
^{签名人:伊利亚·纽伦}

将交互式"后端重命名为合并" ，因为:
'interactive'作为名称引起混乱；此后端已用于多种非交互式rebase，并且如果我们将其设置为默认值，则将来可能会用于非交互式rebase而不是交互式rebase.
互动"不是基本策略；正在合并.
存储状态的目录不是 .git/rebase-interactive ，而是 .git/rebase-merge .

在Git 2.27(2020年第二季度)中，您还可以允许" git rebase "重新应用所有本地提交(即使可能已经在上游)，而无需先检查.

  git rebase --reapply-cherry-picks

这将加快重新设置基准的过程.

请参见提交0fcb4f6 (2020年4月11日)由 Junio C Hamano合并- gitster -在提交d6d561d ，2020年4月22日)

rebase --merge :可以选择跳过上游提交
^{签名人:Jonathan Tan}
^{签名人:伊利亚·纽伦}

在基于自原始分支创建以来已进行多次提交的上游进行基础迁移时:
  O-O-...-O-O(上游)\-O(my-dev-branch) 
除了上游和合并基础之外，它还必须读取每个新颖上游提交的内容，因为" git rebase "尝试排除与上游提交重复的提交.
这可能会严重影响性能，尤其是在部分克隆中，对对象的读取最终可能是获取.
在" git rebase "中添加一个标志-reapply-cherry-picks 以禁止使用此功能.
仅当使用"合并"时，此标志才有效.后端.
此标志更改 sequencer_make_script()的行为，该行为是从 do_interactive_rebase()调用的<- run_rebase_interactive()<-<代码> run_specific_rebase()<- cmd_rebase().使用此标志， limit_list()(通过 prepare_revision_walk()从 sequencer_make_script()间接调用)将不再调用 cherry_pick_list()，因此不再设置 PATCHSAME .
避免设置 PATCHSAME 既意味着不再读取上游的中间提交(如测试所示)，也意味着不执行由 PATCHSAME 引起的跳过提交 sequencer_make_script()，直接或通过 make_script_with_merges().

使用Git 2.30(Q1 2021)，" git-parse-remote "Shell脚本库的作用已不复存在.

请参见提交66d36b9 (2020年11月24日)，由提交a89a2fb ，(2020年11月14日)通过 ÆvarArnfjörðBjarmason( avar ).
^{(由 Junio C Hamano合并- gitster -在提交e89ecfb ，2020年12月3日)}

parse-remote :立即删除此-未使用的库
^{签名人:ÆvarArnfjörðBjarmason}

前两次提交删除了该库中最后一次使用函数的功能，但大部分时间都是无效代码.
仍然仅使用"get_default_remote" 函数.
即使我们为该库提供了手册页，也从未打算(或者我希望实际上是)在 git.git .让我们删除它，如果仍然有人在乎这里的功能，他们可以将其拉入自己的项目中.

最后使用 error_on_missing_default_upstream(): d03ebd411c ("rebase:删除rebase.useBuiltin设置"，2019-03-18)

最后一次使用 get_remote_merge_branch(): 49eb8d39c7 (删除contrib/examples/*"，2018年3月25日)

https://lore.kernel.org/git/87a6vmhdka.fsf@evledraar.gmail.com/

使用Git 2.32(Q2 2021)，过去具有脚本化git rebase的最终提示已被删除.

请参见提交9bcde4d (2021年3月23日)由 Junio C Hamano合并- gitster -在提交dc2a073 ，2021年3月30日)

rebase :删除临时rebase.useBuiltin设置&env
^{签名人:ÆvarArnfjörðBjarmason}
^{代理人:Johannes Schindelin}

删除rebase.useBuiltin设置和现已过时的 GIT_TEST_REBASE_USE_BUILTIN 测试标记.
在我的 d03ebd4 ("rebase:删除rebase.useBuiltin设置"，2019年3月18日，Git v2.22.0-rc0-合并)以帮助您使用过实验性标记并想知道它是默认标记的任何人，或者他们应该转换测试环境以无条件使用内置的rebase.
对于这些用户来说，已经足够长的时间了.因此，请删除 d03ebd4 之后留在原处的所有脚手架.我还删除了文档条目，如果任何人仍保留其配置，他们可以做一些源考古来弄清楚它曾经做什么，这比将每个阅读文档的Git用户暴露于此旧配置开关更有意义.

I use git by creating a series of feature branches, and merging them to master when they're done with git merge --no-ff. This creates empty merge commits useful to identify start and end points of previous feature branches.

In order to handle multiple concurrent branches, or even nested branches, I use rebase. I never merge back, I always rebase my branches upon the latest commits, test and finally merge with --no-ff once everything is done. With nested branches, I do the same: multiple branches are merged sequentially onto the main branch, which is itself merged to master in the end.

In order to keep information about merges with nested branches, I often use git rebase --preserve-merges. This does exactly what I want and I have no problems with my workflow.

My main problem with git is that git rebase --preserve-merges is very slow (sometimes taking about 2 seconds per commit). After reading What exactly does git's "rebase --preserve-merges" do (and why?) I realize that git must perform a lot of work to preserve the merges, since git has to work on arbitrary graphs.

What I was wondering is this: since my workflow pretty much results in a graph equivalent to a linear history, is there a way to perform a git rebase --preserve-merge equivalent in a faster way, given that I guarantee "linearity" of history with only empty merge commits? I don't mind using scripts or weird commands, as long as the final result is correct.

     A-B-C
    /     \   
(1)--------D-- master
    \
     \---F-----I-- feature
      \ / \   /
       E   G-H

     A-B-C   E   G-H
    /     \ / \ /   \
(2)--------D---F-----I-feature
         master

tl; dr: How to transform (1) into (2) knowing that the underlying history is linear so git rebase --preserve-merges doesn't have to do as much work and does it fast?

解决方案

My main problem with git is that git rebase --preserve-merges is very slow

That might not be so slow with Git 2.20+ (Q4 2018), considering it includes a rewrite of the "rebase" machinery in C.
No more shell script. (Let's be clear: starting Git 2.22, Q2 2019, the old rebase script is no more)

See commit ac7f467, commit c7b64aa, commit 55071ea (06 Aug 2018) by Pratik Karki (prertik).
^{(Merged by Junio C Hamano -- gitster -- in commit 5ae5084, 02 Nov 2018)}

rebase: start implementing it as a builtin

This commit imitates the strategy that was used to convert the difftool to a builtin.
We start by renaming the shell script git-rebase.sh to git-legacy-rebase.sh and introduce a builtin/rebase.c that simply executes the shell script version, unless the config setting rebase.useBuiltin is set to true.

The motivation behind this is to rewrite all the functionality of the shell script version in the aforementioned rebase.c, one by one and be able to conveniently test new features by configuring rebase.useBuiltin.

In the original difftool conversion, if sane_execvp() that attempts to run the legacy scripted version returned with non-negative status, the command silently exited without doing anything with success, but sane_execvp() should not return with non-negative status in the first place, so we use die() to notice such an abnormal case.

We intentionally avoid reading the config directly to avoid messing up the GIT_* environment variables when we need to fall back to exec()ing the shell script.

See commit 62c2393, commit d8d0a54 (14 Nov 2018) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit 4520c23, 18 Nov 2018)}

The documentation now states:

rebase.useBuiltin:

Set to false to use the legacy shellscript implementation if git rebase.
Is true by default, which means use the built-in rewrite of it in C.

The C rewrite is first included with Git version 2.20.
This option serves an an escape hatch to re-enable the legacy version in case any bugs are found in the rewrite.
This option and the shellscript version git-rebase will be removed in some future release.

If you find some reason to set this option to false other than one-off testing you should report the behavior difference as a bug in git.

With Git 2.21 (Feb. 2019), "git rebase --merge" as been reimplemented by reusing the internal machinery used for "git rebase -i".

See commit 68aa495, commit c91c944, commit 7b76ac6, commit 899b49c, commit 45339f7, commit 5400677, commit 72ee673, commit c913c59 (11 Dec 2018) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster -- in commit 8fe9c3f, 07 Feb 2019)}

rebase: implement --merge via the interactive machinery

As part of an ongoing effort to make rebase have more uniform behavior, modify the merge backend to behave like the interactive one, by re-implementing it on top of the latter.

Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options.
As such, there really is not any need for having both git-rebase--merge and git-rebase--interactive anymore.
Delete git-rebase--merge.sh and instead implement it in builtin/rebase.c.

rebase: define linearization ordering and enforce it

See commit c91c944 on performance.

Also, still Git 2.21 (Feb. 2019): "git rebase --merge" as been reimplemented by reusing the internal machinery used for "git rebase -i".

See commit 29d03f8 (14 Feb 2019) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster -- in commit 6f07c7b, 14 Feb 2019)}

rebase: implement --merge via the interactive machinery

As part of an ongoing effort to make rebase have more uniform behavior, modify the merge backend to behave like the interactive one, by re-implementing it on top of the latter.

Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options.
As such, there really is not any need for having both git-rebase--merge and git-rebase--interactive anymore.
Delete git-rebase--merge.sh and instead implement it in builtin/rebase.c.

This results in a few deliberate but small user-visible changes:

The progress output is modified (see t3406 and t3420 for examples)

A few known test failures are now fixed (see t3421)

bash-prompt during a rebase --merge is now REBASE-i instead of REBASE-m.
Reason: The prompt is a reflection of the backend in use; this allows users to report an issue to the git mailing list with the appropriate backend information, and allows advanced users to know where to search for relevant control files. (see t9903)

Since "git rebase --preserve-merge" as been reimplemented by reusing the internal machinery used for "git rebase -i", this Git 2.22 (Q2 2019) patch is of interest:

See commit 460bc3c, commit 297b1e1, commit 0ea0847, commit 73fdc53, commit 3389853, commit 7d3488e, commit c44c246, commit 0609b74, commit 6023c92, commit 28dc09d, commit 146839c (17 Apr 2019), and commit fc4a673 (19 Mar 2019) by Phillip Wood (phillipwood).
^{(Merged by Junio C Hamano -- gitster -- in commit 7ba06bc, 13 May 2019)}

rebase -i: run without forking rebase --interactive

When the builtin rebase starts an interactive rebase it parses the options and then repackages them and forks rebase--interactive.
Separate the option parsing in cmd_rebase__interactive() from the business logic to allow interactive rebases can be run without forking rebase__interactive by calling run_rebase_interactive() directly.

Starting interactive rebases without forking makes it easy to debug the sequencer without worrying about attaching to child processes.
Ævar has also reported that some of the rebase perf tests are 30% faster.

This patch also makes it easy to remove cmd_rebase__interactive() in the future when git-legacy-rebase.sh and git-rebase--preserve-merges.sh are retired.

As mentioned at the beginning of the answer:

Git 2.22 (Apr. 2019) has retired the old git rebase script.
See commit d03ebd4 (18 Mar 2019) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit 4f3036c, 16 Apr 2019)}
Git 2.23 (Q3 2019) finalize the cleanup, and points out that the only remaining scripted part of git rebase is the --preserve-merges backend.
See commit 082ef75, commit c3c003e, commit d4fe60e, commit b2b9a23, commit 311c00a (14 May 2019) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit ed7f8ac, 13 Jun 2019)}

"git rebase -i" (and friends) used to unnecessarily check out the tip of the branch to be rebased, which has been corrected with Git 2.26 (Q1 2020),

See commit 767a9c4 (24 Jan 2020) by Alban Gruin (``).
^{(Merged by Junio C Hamano -- gitster -- in commit d8b8d59, 14 Feb 2020)}

rebase -i: stop checking out the tip of the branch to rebase

^{Reported-by: SZEDER Gábor}
^{Signed-off-by: Alban Gruin}

One of the first things done when using a sequencer-based rebase (ie. rebase -i, rebase -r, or rebase -m) is to make a todo list.

This requires knowledge of the commit range to rebase.

To get the oid of the last commit of the range, the tip of the branch to rebase is checked out with prepare_branch_to_be_rebased(), then the oid of the head is read.

After this, the tip of the branch is not even modified. The `am' backend, on the other hand, does not check out the branch.

On big repositories, it's a performance penalty: with rebase -i', the user may have to wait before editing the todo list while git is extracting the branch silently, and "quiet" rebases will be slower than am'.

Since we already have the oid of the tip of the branch in opts->orig_head, it's useless to switch to this commit.

This removes the call to prepare_branch_to_be_rebased() in do_interactive_rebase(), and adds a orig_head' parameter to get_revision_ranges()`.

prepare_branch_to_be_rebased() is removed as it is no longer used.

This introduces a visible change: as we do not switch on the tip of the branch to rebase, no reflog entry is created at the beginning of the rebase for it.

Unscientific performance measurements, performed on linux.git, are as follow:

Before this patch:
$ time git rebase -m --onto v4.18 463fa44eec2fef50~ 463fa44eec2fef50

real    0m8,940s
user    0m6,830s
sys     0m2,121s
After this patch:
$ time git rebase -m --onto v4.18 463fa44eec2fef50~ 463fa44eec2fef50

real    0m1,834s
user    0m0,916s
sys     0m0,206s

As notes with Git 2.26 (Q1 2020), "git rebase" has learned to use the merge backend (i.e. the machinery that drives "rebase -i") by default, while allowing "--apply" option to use the "apply" backend (e.g. the moral equivalent of "format-patch piped to am").

The rebase.backend configuration variable can be set to customize.

See commit 10cdb9f, commit 2ac0d62, commit 8295ed6, commit 76340c8, commit 980b482, commit c2417d3, commit 6d04ce7, commit 52eb738, commit 8af14f0, commit be50c93, commit befb89c, commit 9a70f3d, commit 93122c9, commit 55d2b6d, commit 8a997ed, commit 7db00f0, commit e98c426, commit d48e5e2 (15 Feb 2020), and commit a9ae8fd, commit 22a69fd (16 Jan 2020) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster -- in commit 8c22bd9, 02 Mar 2020)}

rebase: rename the two primary rebase backends

^{Signed-off-by: Elijah Newren}

Rename the 'interactive' backend to 'merge' because:

'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default.

'interactive' is not the underlying strategy; merging is.

the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge.

With Git 2.27 (Q2 2020), you can also allow "git rebase" to reapply all local commits, even if the may be already in the upstream, without checking first.

git rebase --reapply-cherry-picks

That would accelerate the rebase process.

See commit 0fcb4f6 (11 Apr 2020) by Jonathan Tan (jhowtan).
^{(Merged by Junio C Hamano -- gitster -- in commit d6d561d, 22 Apr 2020)}

rebase --merge: optionally skip upstreamed commits

^{Signed-off-by: Jonathan Tan}
^{Signed-off-by: Elijah Newren}

When rebasing against an upstream that has had many commits since the original branch was created:
O -- O -- ... -- O -- O (upstream)
 \
  -- O (my-dev-branch)
it must read the contents of every novel upstream commit, in addition to the tip of the upstream and the merge base, because "git rebase" attempts to exclude commits that are duplicates of upstream ones.

This can be a significant performance hit, especially in a partial clone, wherein a read of an object may end up being a fetch.

Add a flag --reapply-cherry-picks to "git rebase" to allow suppression of this feature.
This flag only works when using the "merge" backend.

This flag changes the behavior of sequencer_make_script(), called from do_interactive_rebase() <- run_rebase_interactive() <- run_specific_rebase() <- cmd_rebase(). With this flag, limit_list() (indirectly called from sequencer_make_script() through prepare_revision_walk()) will no longer call cherry_pick_list(), and thus PATCHSAME is no longer set.
Refraining from setting PATCHSAME both means that the intermediate commits in upstream are no longer read (as shown by the test) and means that no PATCHSAME-caused skipping of commits is done by sequencer_make_script(), either directly or through make_script_with_merges().

With Git 2.30 (Q1 2021), "git-parse-remote" shell script library outlived its usefulness.

See commit 66d36b9 (24 Nov 2020) by Jeff King (peff).
See commit a89a2fb, commit e63f7b0, commit 1c15180 (14 Nov 2020) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit e89ecfb, 03 Dec 2020)}

parse-remote: remove this now-unused library

^{Signed-off-by: Ævar Arnfjörð Bjarmason}

The previous two commits removed the last use of a function in this library, but most of it had been dead code for a while.
Only the "get_default_remote" function was still being used.

Even though we had a manual page for this library it was never intended (or I expect, actually) used outside of git.git. Let's just remove it, if anyone still cares about a function here they can pull them into their own project.

Last use of error_on_missing_default_upstream(): d03ebd411c ("rebase: remove the rebase.useBuiltin setting", 2019-03-18)

Last use of get_remote_merge_branch(): 49eb8d39c7 ("Remove> contrib/examples/*", 2018-03-25)

https://lore.kernel.org/git/87a6vmhdka.fsf@evledraar.gmail.com/

With Git 2.32 (Q2 2021), the final hint that used to have a scripted git rebase is removed.

See commit 9bcde4d (23 Mar 2021) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit dc2a073, 30 Mar 2021)}

rebase: remove transitory rebase.useBuiltin setting & env

^{Signed-off-by: Ævar Arnfjörð Bjarmason}
^{Acked-by: Johannes Schindelin}

Remove the rebase.useBuiltin setting and the now-obsolete GIT_TEST_REBASE_USE_BUILTIN test flag.

This was left in place after my d03ebd4 ("rebase: remove the rebase.useBuiltin setting", 2019-03-18, Git v2.22.0-rc0 -- merge listed in batch #5) to help anyone who'd used the experimental flag and wanted to know that it was the default, or that they should transition their test environment to use the builtin rebase unconditionally.

It's been more than long enough for those users to get a headsup about this.
So remove all the scaffolding that was left in-place after d03ebd4.
I'm also removing the documentation entry, if anyone still has this left in their configuration they can do some source archaeology to figure out what it used to do, which makes more sense than exposing every Git user reading the documentation to this legacy configuration switch.

这篇关于git rebase --preserve-merges的更快方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文

git rebase --preserve-merges的更快方法 [英] A faster way to `git rebase --preserve-merges`

问题描述

变基:开始将其实现为内置

`rebase` :通过交互机制实现`-合并`

`rebase` :定义线性化顺序并强制执行

rebase:通过交互式机器实现--merge

`rebase -i` :运行时不会分叉 `rebase --interactive`

`rebase -i` :停止检查要重新建立分支的尖端

`rebase` :重命名两个主要的rebase后端

`rebase --merge` :可以选择跳过上游提交

`parse-remote` :立即删除此-未使用的库

`rebase` :删除临时rebase.useBuiltin设置&env

rebase: start implementing it as a builtin

`rebase`: implement `--merge` via the interactive machinery

`rebase`: define linearization ordering and enforce it

rebase: implement --merge via the interactive machinery

`rebase -i`: run without forking `rebase --interactive`

`rebase -i`: stop checking out the tip of the branch to rebase

`rebase`: rename the two primary rebase backends

`rebase --merge`: optionally skip upstreamed commits

`parse-remote`: remove this now-unused library

`rebase`: remove transitory rebase.useBuiltin setting & env

相关文章

其他开发最新文章

热门教程

热门工具

登录关闭

git rebase --preserve-merges的更快方法 [英] A faster way to `git rebase --preserve-merges`

问题描述

变基:开始将其实现为内置

rebase :通过交互机制实现-合并

rebase :定义线性化顺序并强制执行

rebase:通过交互式机器实现--merge

rebase -i :运行时不会分叉 rebase --interactive

rebase -i :停止检查要重新建立分支的尖端

rebase :重命名两个主要的rebase后端

rebase --merge :可以选择跳过上游提交

parse-remote :立即删除此-未使用的库

rebase :删除临时rebase.useBuiltin设置&env

rebase: start implementing it as a builtin

rebase: implement --merge via the interactive machinery

rebase: define linearization ordering and enforce it

rebase: implement --merge via the interactive machinery

rebase -i: run without forking rebase --interactive

rebase -i: stop checking out the tip of the branch to rebase

rebase: rename the two primary rebase backends

rebase --merge: optionally skip upstreamed commits

parse-remote: remove this now-unused library

rebase: remove transitory rebase.useBuiltin setting & env

相关文章

其他开发最新文章

热门教程

热门工具

登录 关闭

`rebase` :通过交互机制实现`-合并`

`rebase` :定义线性化顺序并强制执行

`rebase -i` :运行时不会分叉 `rebase --interactive`

`rebase -i` :停止检查要重新建立分支的尖端

`rebase` :重命名两个主要的rebase后端

`rebase --merge` :可以选择跳过上游提交

`parse-remote` :立即删除此-未使用的库

`rebase` :删除临时rebase.useBuiltin设置&env

`rebase`: implement `--merge` via the interactive machinery

`rebase`: define linearization ordering and enforce it

`rebase -i`: run without forking `rebase --interactive`

`rebase -i`: stop checking out the tip of the branch to rebase

`rebase`: rename the two primary rebase backends

`rebase --merge`: optionally skip upstreamed commits

`parse-remote`: remove this now-unused library

`rebase`: remove transitory rebase.useBuiltin setting & env

登录关闭