git rebase 在 git 中停止工作 windows
git rebase stopped working in git for windows
我在 git rebase 中观察到非常奇怪的崩溃。
我正在执行的操作没有改变，但他们的结果已经从一段时间前改变了。
我从 git rebase 获得帮助信息，而不是 rebased 分支，描述命令行选项，和带有一些十六进制数字的文件 bash.exe.stackdump。
在执行 git pull --rebase 期间观察到相同的行为。 Rebasing pull commits 是我的默认设置，因此这种不当行为非常烦人。
示例：
$ git rebase master feature/tune-logging
usage: git rebase [-i] [options] [--exec <cmd>] [--onto <newbase>] [<upstream>] [<branch>]
or: git rebase [-i] [options] [--exec <cmd>] [--onto <newbase>] --root [<branch>]
or: git rebase --continue | --abort | --skip | --edit-todo
Available options are
-v, --verbose display a diffstat of what changed upstream
-q, --quiet be quiet. implies --no-stat
--autostash automatically stash/stash pop before and after
--fork-point ....
[ skip ... ]
Actions:
--continue continue
--abort abort and check out the original branch
--skip skip current patch and continue
--edit-todo edit the todo list during an interactive rebase
--quit abort but keep HEAD where it is
--show-current-patch show the patch file being applied or merged
我使用 Windows 7 x64，最近有更新。
git 版本 2.18.0.windows.1
我也使用 SmartGit，运行 相同的 git 可执行文件。
这是通过GIT_TRACE=2
获得的输出
$ GIT_TRACE=2 git rebase master feature/tune-logging
11:13:05.925709 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/bin
11:13:05.927709 git.c:654 trace: exec: git-rebase master feature/tune-logging
11:13:05.927709 run-command.c:637 trace: run_command: git-rebase master feature/tune-logging
11:13:06.348751 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:09.354050 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:09.356050 git.c:415 trace: built-in: git rev-parse --git-dir
11:13:09.778092 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:09.779092 git.c:415 trace: built-in: git rev-parse --git-path objects
11:13:10.122126 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:10.123126 git.c:415 trace: built-in: git rev-parse --is-bare-repository
11:13:10.452159 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:10.453159 git.c:415 trace: built-in: git rev-parse --show-toplevel
11:13:10.827196 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:10.829197 git.c:415 trace: built-in: git config --bool rebase.stat
11:13:11.210235 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:11.212235 git.c:415 trace: built-in: git config --bool rebase.autostash
11:13:11.548269 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:11.550269 git.c:415 trace: built-in: git config --bool rebase.autosquash
11:13:11.869301 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:11.871301 git.c:415 trace: built-in: git config --bool commit.gpgsign
11:13:12.330347 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:12.754389 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:12.755389 git.c:415 trace: built-in: git rev-parse --parseopt --stuck-long -- -h
usage: git rebase [-i] [options] [--exec <cmd>] [--onto <newbase>] [<upstream>] [<branch>]
or: git rebase [-i] [options] [--exec <cmd>] [--onto <newbase>] --root [<branch>]
or: git rebase --continue | --abort | --skip | --edit-todo
Available options are
-v, --verbose display a diffstat of what changed upstream
-q, --quiet be quiet. implies --no-stat
--autostash automatically stash/stash pop before and after
[skip ]
分支 master 和 feature/tune-logging 确实存在。
更新.
尝试回滚 git 到某个以前的版本。
随机选择 git 版本 2.12.2 工作正常，但导致 SmartGit 抱怨太旧 git 并建议至少使用版本 2.16
已升级 git 到 2.16.2 - 同样的崩溃。
更新 2.
我描述我的实验。
在 master 的一些旧提交上创建一个新分支，添加虚拟文件，提交，删除虚拟文件，提交，变基：
--c1--c2--c3--master
\
d1-add dummy file--d2-remove dummy file--
更新 3
已尝试 git 版本 2.15 和 2.14。版本 2.15 出现相同的崩溃，版本 2.14 有效。
暂时停止，直到崩溃的原因得到解决。我将尝试提供有关订单的更多信息以找到它。
更新 4
我通常使用 SmartGit，它是 git 的 GUI 前端，但以上所有结果都是使用命令行获得的。
已将 git 更新至 2.19，问题已解决。
在安装新的 git 版本时，安装向导显示了两个复选框，要求打开新的实验性内置功能：变基和存储。
我没有检查它们。
已将更新为git 2.19.1.windows.1，现在打开这些复选框。一切仍然有效。
内置 git rebase 现在在 Git 2.21（2019 年 2 月）中更加完整，因为不用通过“git-rebase--am”脚本来使用“am”后端，内置版本"git rebase"学会了直接驱动“am”后端。
参见 commit 2185362, commit 414f336, commit 5b2237a, commit c523370 (18 Jan 2019) by Johannes Schindelin (dscho)。
（由 Junio C Hamano -- gitster -- in commit e52c6bb 合并，2019 年 2 月 7 日）
built-in rebase: call git am directly
Signed-off-by: Johannes Schindelin
While the scripted git rebase still has to rely on the git-rebase--am.sh script to implement the glue between the rebase and the am commands, we can go a more direct route in the built-in rebase and avoid using a shell script altogether.
This patch represents a straight-forward port of git-rebase--am.sh to C, along with the glue code to call it directly from within builtin/rebase.c.
This reduces the chances of Git for Windows running into trouble due to problems with the POSIX emulation layer (known as "MSYS2 runtime", itself a derivative of the Cygwin runtime): when no shell script is called, the POSIX emulation layer is avoided altogether.
（实际上，随着 Git 2.22，2019 年第 2 季度，内置的 rebase 已完成且稳定，old script rebase is no more）
在 Git 2.25（2020 年第一季度）中，“git rebase --signoff”在用 C 编写命令时停止工作，已更正。
参见 commit 4fe7e43 (20 Dec 2019) by Elijah Newren (newren)。
（由 Junio C Hamano -- gitster -- in commit e0e1ac5 合并，2020 年 1 月 2 日）
rebase: fix saving of --signoff state for am-based rebases
Signed-off-by: Elijah Newren
This was an error introduced in the conversion from shell in commit 21853626eac5 ("built-in rebase: call git am directly", 2019-01-18, Git v2.21.0-rc0 -- merge, seen above), which was noticed by a random browsing of the code.
如 Git 2.26（2020 年第一季度）中所述，“git rebase”现在使用“--apply”选项来使用“apply”后端（例如，“format-patch piped to am”的道德等价物。
The rebase.backend configuration variable can be set to customize.
参见 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)。
（由 Junio C Hamano -- gitster -- in commit 8c22bd9 合并，2020 年 3 月 2 日）
rebase: rename the two primary rebase backends
Signed-off-by: Elijah Newren
Rename the 'am' backend to 'apply' because:
- Few users are familiar with git-am as a reference point.
- Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems.
- Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing.
- While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too.
- The directory where state is stored has never been called
.git/rebase-am, it was always called .git/rebase-apply.
我在 git rebase 中观察到非常奇怪的崩溃。 我正在执行的操作没有改变，但他们的结果已经从一段时间前改变了。
我从 git rebase 获得帮助信息，而不是 rebased 分支，描述命令行选项，和带有一些十六进制数字的文件 bash.exe.stackdump。
在执行 git pull --rebase 期间观察到相同的行为。 Rebasing pull commits 是我的默认设置，因此这种不当行为非常烦人。
示例：
$ git rebase master feature/tune-logging
usage: git rebase [-i] [options] [--exec <cmd>] [--onto <newbase>] [<upstream>] [<branch>]
or: git rebase [-i] [options] [--exec <cmd>] [--onto <newbase>] --root [<branch>]
or: git rebase --continue | --abort | --skip | --edit-todo
Available options are
-v, --verbose display a diffstat of what changed upstream
-q, --quiet be quiet. implies --no-stat
--autostash automatically stash/stash pop before and after
--fork-point ....
[ skip ... ]
Actions:
--continue continue
--abort abort and check out the original branch
--skip skip current patch and continue
--edit-todo edit the todo list during an interactive rebase
--quit abort but keep HEAD where it is
--show-current-patch show the patch file being applied or merged
我使用 Windows 7 x64，最近有更新。 git 版本 2.18.0.windows.1
我也使用 SmartGit，运行 相同的 git 可执行文件。
这是通过GIT_TRACE=2
$ GIT_TRACE=2 git rebase master feature/tune-logging
11:13:05.925709 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/bin
11:13:05.927709 git.c:654 trace: exec: git-rebase master feature/tune-logging
11:13:05.927709 run-command.c:637 trace: run_command: git-rebase master feature/tune-logging
11:13:06.348751 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:09.354050 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:09.356050 git.c:415 trace: built-in: git rev-parse --git-dir
11:13:09.778092 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:09.779092 git.c:415 trace: built-in: git rev-parse --git-path objects
11:13:10.122126 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:10.123126 git.c:415 trace: built-in: git rev-parse --is-bare-repository
11:13:10.452159 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:10.453159 git.c:415 trace: built-in: git rev-parse --show-toplevel
11:13:10.827196 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:10.829197 git.c:415 trace: built-in: git config --bool rebase.stat
11:13:11.210235 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:11.212235 git.c:415 trace: built-in: git config --bool rebase.autostash
11:13:11.548269 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:11.550269 git.c:415 trace: built-in: git config --bool rebase.autosquash
11:13:11.869301 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:11.871301 git.c:415 trace: built-in: git config --bool commit.gpgsign
11:13:12.330347 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:12.754389 exec-cmd.c:236 trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
11:13:12.755389 git.c:415 trace: built-in: git rev-parse --parseopt --stuck-long -- -h
usage: git rebase [-i] [options] [--exec <cmd>] [--onto <newbase>] [<upstream>] [<branch>]
or: git rebase [-i] [options] [--exec <cmd>] [--onto <newbase>] --root [<branch>]
or: git rebase --continue | --abort | --skip | --edit-todo
Available options are
-v, --verbose display a diffstat of what changed upstream
-q, --quiet be quiet. implies --no-stat
--autostash automatically stash/stash pop before and after
[skip ]
分支 master 和 feature/tune-logging 确实存在。
更新.
尝试回滚 git 到某个以前的版本。
随机选择 git 版本 2.12.2 工作正常，但导致 SmartGit 抱怨太旧 git 并建议至少使用版本 2.16
已升级 git 到 2.16.2 - 同样的崩溃。
更新 2.
我描述我的实验。
在 master 的一些旧提交上创建一个新分支，添加虚拟文件，提交，删除虚拟文件，提交，变基：
--c1--c2--c3--master
\
d1-add dummy file--d2-remove dummy file--
更新 3
已尝试 git 版本 2.15 和 2.14。版本 2.15 出现相同的崩溃，版本 2.14 有效。
暂时停止，直到崩溃的原因得到解决。我将尝试提供有关订单的更多信息以找到它。
更新 4
我通常使用 SmartGit，它是 git 的 GUI 前端，但以上所有结果都是使用命令行获得的。
已将 git 更新至 2.19，问题已解决。
在安装新的 git 版本时，安装向导显示了两个复选框，要求打开新的实验性内置功能：变基和存储。
我没有检查它们。
已将更新为git 2.19.1.windows.1，现在打开这些复选框。一切仍然有效。
内置 git rebase 现在在 Git 2.21（2019 年 2 月）中更加完整，因为不用通过“git-rebase--am”脚本来使用“am”后端，内置版本"git rebase"学会了直接驱动“am”后端。
参见 commit 2185362, commit 414f336, commit 5b2237a, commit c523370 (18 Jan 2019) by Johannes Schindelin (dscho)。
（由 Junio C Hamano -- gitster -- in commit e52c6bb 合并，2019 年 2 月 7 日）
built-in rebase: callgit amdirectlySigned-off-by: Johannes Schindelin
While the scripted
git rebasestill has to rely on thegit-rebase--am.shscript to implement the glue between therebaseand theamcommands, we can go a more direct route in the built-in rebase and avoid using a shell script altogether.This patch represents a straight-forward port of
git-rebase--am.shto C, along with the glue code to call it directly from withinbuiltin/rebase.c.This reduces the chances of Git for Windows running into trouble due to problems with the POSIX emulation layer (known as "MSYS2 runtime", itself a derivative of the Cygwin runtime): when no shell script is called, the POSIX emulation layer is avoided altogether.
（实际上，随着 Git 2.22，2019 年第 2 季度，内置的 rebase 已完成且稳定，old script rebase is no more）
在 Git 2.25（2020 年第一季度）中，“git rebase --signoff”在用 C 编写命令时停止工作，已更正。
参见 commit 4fe7e43 (20 Dec 2019) by Elijah Newren (newren)。
（由 Junio C Hamano -- gitster -- in commit e0e1ac5 合并，2020 年 1 月 2 日）
rebase: fix saving of --signoff state for am-based rebasesSigned-off-by: Elijah Newren
This was an error introduced in the conversion from shell in commit 21853626eac5 ("built-in rebase: call
git amdirectly", 2019-01-18, Git v2.21.0-rc0 -- merge, seen above), which was noticed by a random browsing of the code.
如 Git 2.26（2020 年第一季度）中所述，“git rebase”现在使用“--apply”选项来使用“apply”后端（例如，“format-patch piped to am”的道德等价物。
The
rebase.backendconfiguration variable can be set to customize.
参见 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)。
（由 Junio C Hamano -- gitster -- in commit 8c22bd9 合并，2020 年 3 月 2 日）
rebase: rename the two primary rebase backendsSigned-off-by: Elijah Newren
Rename the 'am' backend to 'apply' because:
- Few users are familiar with git-am as a reference point.
- Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems.
- Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing.
- While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too.
- The directory where state is stored has never been called
.git/rebase-am, it was always called.git/rebase-apply.