Skip to content

Fix ORIG_HEAD behavior of the built-in rebase

Johannes Schindelin via GitGitGadget git 2 versions – New

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v2 Latest4 patches 0 repliesNew
  2. v14 patches 6 repliesSuperseded

Changes in v2 from the cover letter

* Reworded the unclear commit message of patch 1/4.

Patches in v2 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/4built-in rebase: no need to check out `onto` twicebuiltin/rebase.c+2 -20 replies
2/4built-in rebase: use the correct reflog when switching branchesbuiltin/rebase.c+1 -10 replies
3/4built-in rebase: demonstrate that ORIG_HEAD is not set correctlyt/t3400-rebase.sh+8 -00 replies
4/4built-in rebase: set ORIG_HEAD just once, before the rebasebuiltin/rebase.c t/t3400-rebase.sh+19 -140 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.

Read the v2 thread

Cover letter [PATCH v2 0/4] Fix ORIG_HEAD behavior of the built-in rebase

It was reported by Nazri Ramliy that ORIG_HEAD was set incorrectly again, this time caused by the shortcut to call git am directly, without detouring to a Unix shell script.

Patch 2/4 might look like something completely unrelated, but without it, the update to HEAD might use an incorrect reflog message.

Patch 1/4 is more a "while at it" patch; while looking which code paths might need to update ORIG_HEAD, I noticed that this reset_head() call did unnecessary work.

Changes since v1:

* Reworded the unclear commit message of patch 1/4.

Johannes Schindelin (4):
built-in rebase: no need to check out onto twice built-in rebase: use the correct reflog when switching branches built-in rebase: demonstrate that ORIG_HEAD is not set correctly built-in rebase: set ORIG_HEAD just once, before the rebase

 builtin/rebase.c  | 37 +++++++++++++++++++++----------------
 t/t3400-rebase.sh |  8 ++++++++
 2 files changed, 29 insertions(+), 16 deletions(-)

base-commit: 21853626eac565dd42572d90724b29863f61eb3b
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-153%2Fdscho%2Frebase-am-and-orig-head-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-153/dscho/rebase-am-and-orig-head-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/153

Range-diff vs v1:

1: 2d99429387 ! 1: 59c3266ed5 built-in rebase: no need to check out onto twice
@@ -4,12 +4,21 @@

In the case that the rebase boils down to a fast-forward, the built-in rebase reset the working tree twice: once to start the rebase at onto,
- then realizing that the original HEAD was an ancestor, reset_head()
- was called to update the original ref and to point HEAD back to it.
+ then realizing that the original (pre-rebase) HEAD was an ancestor and
+ we basically already fast-forwarded to the post-rebase HEAD,
+ reset_head() was called to update the original ref and to point HEAD
+ back to it.

That second reset_head() call does not need to touch the working tree,
- though, as it does not change the actual tip commit. So let's avoid that
- unnecessary work.
+ though, as it does not change the actual tip commit (and therefore the
+ working tree should stay unchanged anyway): only the ref needs to be
+ updated (because the rebase detached the HEAD, and we want to go back to
+ the branch on which the rebase was started).
+
+ But that second reset_head() was called without the flag to leave the
+ working tree alone (the reason: when that call was introduced, that flag
+ was not yet even thought of). Let's avoid that unnecessary work by
+ passing that flag.

 2:  b92d76065d = 2:  67e41c032a built-in rebase: use the correct reflog when switching branches
 3:  1bc3cbad26 = 3:  17737998f4 built-in rebase: demonstrate that ORIG_HEAD is not set correctly
 4:  1786c172ef = 4:  7891c05f51 built-in rebase: set ORIG_HEAD just once, before the rebase
Signature · 1 line
gitgitgadget