Hi Junio, Le 2023-01-07 à 21:05, Junio C Hamano a écrit : > "Philippe Blain via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> The command used in the example to abort the cherry-pick is 'git reset >> --merge ORIG_HEAD', but cherry-pick does not write 'ORIG_HEAD' before >> starting its operation. > > Sorry, but I am confused. Doesn't <1> update ORIG_HEAD used by <3>? > >> $ git cherry-pick topic^ <1> >> $ git diff <2> >> -$ git reset --merge ORIG_HEAD <3> >> +$ git cherry-pick --abort <3> >> $ git cherry-pick -Xpatience topic^ <4> >> ------------ >> <1> apply the change that would be shown by `git show topic^`. > No, as far as I was able to test and from my reading of the code, cherry-pick does not write ORIG_HEAD. Here is a little script that demonstrates this: ``` #!/bin/sh rm -rf test git -c init.defaultBranch=master init test ( cd test echo hello>file git add file git commit -m initial git branch other echo two>>file git commit -am two git checkout other echo three >>file git commit -am three git checkout master # This writes ORIG_HEAD as 'two' git reset HEAD^ git commit -a -m two-redone # This does not git cherry-pick other # This shows ORIG_HEAD written by reset: echo ORIG_HEAD is: git log --oneline -1 ORIG_HEAD # Whereas HEAD is 'two-redone': echo HEAD is: git log --oneline -1 HEAD ) ``` Looking at the code, 'git grep -p ORIG_HEAD \*.c' reveals the only builtin that write ORIG_HEAD are am, merge, rebase and reset, and the only library code that involves ORIG_HEAD is reset.c::reset_head. Moreover, 'git grep -p [^a-z_]reset_head \*.c' reveals that the only non-builtin user of reset.c::reset_head is sequencer.c::create_autostash, in which the RESET_ORIG_HEAD flag of 'struct reset_head_opts ropts' is not set. That is what convinced me that cherry-pick does not write ORIG_HEAD. Thanks, Philippe.