How to retrieve the right commit hash?

Question

I had a master with a few commits, I moved back to the first commit, created a branch from there and used cherry-pick to apply one of the commits from the master branch. But due to some conflicts I got a message like:

Automatic cherry-pick failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result with: 

    git commit -c some_hash_id

The problem is, resolving the conflicts took me a while and in the meantime I closed the terminal with the message and now I don't know what commit hash I should use when committing the resolved files. How do I find it out?

If I didn't provide enough details, please ask for them in the comments.

Edit:

$ git status
# On branch upgrade
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   file1.php
#   new file:   file2.php
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   both modified:      file3.php
#   both modified:      file4.php
#   both modified:      file5.php
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   [long list of files...]

file3.php, file4.php and file5.php are the ones I had to resolve conflicts in.

$ git cherry-pick --continue
error: unknown option `continue'
usage: git cherry-pick [options] <commit-ish>

    -n, --no-commit       don't automatically commit
    -e, --edit            edit the commit message
    -x                    append commit name when cherry-picking
    -r                    no-op (backward compatibility)
    -s, --signoff         add Signed-off-by:
    -m, --mainline <n>    parent number
    --rerere-autoupdate   update the index with reused conflict resolution if possible
    --ff                  allow fast-forward

$ git cherry-pick --abort
error: unknown option `abort'
usage: git cherry-pick [options] <commit-ish>

    -n, --no-commit       don't automatically commit
    -e, --edit            edit the commit message
    -x                    append commit name when cherry-picking
    -r                    no-op (backward compatibility)
    -s, --signoff         add Signed-off-by:
    -m, --mainline <n>    parent number
    --rerere-autoupdate   update the index with reused conflict resolution if possible
    --ff                  allow fast-forward

But the docs say:

--continue

    Continue the operation in progress using the information in .git/sequencer. Can be used to continue after resolving conflicts in a failed cherry-pick or revert.

And I don't have such file (I checked) so maybe I can't use these commands now.

I'm using git version 1.7.1.

Answer 1

Git 2.22 (Q2 2019, 4 years later) should do a better job keeping the status of a cherry-pick or revert which resolving conflicts.

See commit 4a72486, commit b07d9bf (16 Apr 2019) by Phillip Wood (phillipwood).
^{(Merged by Junio C Hamano -- gitster -- in commit b51a0fd, 13 May 2019)}

fix cherry-pick/revert status after commit

If the user commits a conflict resolution using git commit in the middle of a sequence of cherry-picks/reverts then git status missed the fact that a cherry-pick/revert is still in progress.

And:

commit/reset: try to clean up sequencer state

When cherry-picking or reverting a sequence of commits and if the final pick/revert has conflicts and the user uses git commit to commit the conflict resolution and does not run git cherry-pick --continue then the sequencer state is left behind.

This can cause problems later.

In my case I cherry-picked a sequence of commits the last one of which I committed with git commit after resolving some conflicts, then a while later, on a different branch I aborted a revert which rewound my HEAD to the end of the cherry-pick sequence on the previous branch.

Avoid this potential problem by removing the sequencer state if we're committing or resetting the final pick in a sequence.

---

With Git 2.23 (Q3 2019), the code to read state files used by the sequencer machinery for "git status" has been made more robust against a corrupt or stale state files.

See commit ed5b1ca, commit 3e81bcc, commit d258dc1 (27 Jun 2019) by Phillip Wood (phillipwood).
^{(Merged by Junio C Hamano -- gitster -- in commit bd48ccf, 19 Jul 2019)}

status: do not report errors in sequencer/todo

commit 4a72486 ("fix cherry-pick/revert status after commit", 2019-04-16, Git v2.22.0-rc0) used parse_insn_line() to parse the first line of the todo list to check if it was a pick or revert.

However, if the todo list is left over from an old cherry-pick or revert and references a commit that no longer exists then parse_insn_line() prints an error message which is confusing for users.

Instead parse just the command name so that the user is alerted to the presence of stale sequencer state by status reporting that a cherry-pick or revert is in progress.

Note that we should not be leaving stale sequencer state lying around (or at least not as often) after commit b07d9bf ("commit/reset: try to clean up sequencer state", 2019-04-16, Git v2.22.0-rc0).
However, the user may still have stale state that predates that commit.

Also avoid printing an error message if for some reason the user has a file called sequencer in $GIT_DIR.

---

During a cherry-pick or revert session that works on multiple commits, "git status"^(man) did not give correct information, which has been corrected with Git 2.42 (Q3 2023).

See commit a096a88 (27 Jun 2023) by Jacob Keller (jacob-keller).
^{(Merged by Junio C Hamano -- gitster -- in commit 391414e, 06 Jul 2023)}

a096a889f4:fix cherry-pick/revert status when doing multiple commits

^{Signed-off-by: Jacob Keller}

The status report for an in-progress cherry-pick does not show the current commit if the cherry-pick happens as part of a series of multiple commits: $ git cherry-pick^(man) < one of the cherry-picks fails to merge clean > Cherry-pick currently in progress.
(run "git cherry-pick" --continue to continue) (use "git cherry-pick --skip"^(man) to skip this patch) (use "git cherry-pick --abort"^(man) to cancel the cherry-pick operation) $ git status^(man) On branch <branch> Your branch is ahead of '' by 1 commit.
(use "git push to"^(man) publish your local commits) Cherry-pick currently in progress.
(run "git cherry-pick" --continue to continue) (use "git cherry-pick --skip" to skip this patch) (use "git cherry-pick --abort" to cancel the cherry-pick operation)

The show_cherry_pick_in_progress() function prints "Cherry-pick currently in progress".
That function does have a more verbose print based on whether the cherry_pick_head_oid is null or not.
If it is not null, then a more helpful message including which commit is actually being picked is displayed.

The introduction of the "Cherry-pick currently in progress" message comes from 4a72486 ("fix cherry-pick/revert status after commit", 2019-04-17, Git v2.22.0-rc0 -- merge).
This commit modified wt_status_get_state() in order to detect that a cherry-pick was in progress even if the user has used git commit^(man) in the middle of the sequence.

The check used to detect this is the call to sequencer_get_last_command.
If the sequencer indicates that the lass command was a REPLAY_PICK, then the state->cherry_pick_in_progress is set to 1 and the cherry_pick_head_oid is initialized to the null_oid.
Similar behavior is done for the case of REPLAY_REVERT.

It happens that this call of sequencer_get_last_command will always report the action even if the user hasn't interrupted anything.
Thus, during a range of cherry-picks or reverts, the cherry_pick_head_oid and revert_head_oid will always be overwritten and initialized to the null oid.

This results in status always displaying the terse message which does not include commit information.

Fix this by adding an additional check so that we do not re-initialize the cherry_pick_head_oid or revert_head_oid if we have already set the cherry_pick_in_progress or revert_in_progress bits.
This ensures that git status will display the more helpful information when its available.