> Hello,
> 
> When running `git cherry-pick` over a range of commits, the command may 
> stop due to conflicts. At that point Git reports the conflict but does 
> not provide an easy way to see which commit is currently being cherry- 
> picked or what patch is being applied.
> 
> `git rebase` provides a helpful option for this situation:
> 
> `git rebase --show-current-patch`
> 
> This prints the patch of the commit that is currently being applied. I 
> believe a similar feature would be useful for `git cherry-pick`.

> Currently, when a conflict occurs during a range cherry-pick (e.g. `git 
> cherry-pick A..B`), there is no straightforward command to show the 
> patch of the commit being applied. While it is possible to inspect 
> `.git/CHERRY_PICK_HEAD`and run something like:
> 
> `git show $(cat .git/CHERRY_PICK_HEAD)`
> 
> this is not very discoverable and requires manual steps.
> 
> 
> Proposed feature
> 
> Add a command:
> 
> `git cherry-pick --show-current-patch`
> 
> which would display the patch of the commit currently being applied 
> during an in-progress cherry-pick operation (similar to `git rebase -- 
> show-current-patch`).
> 
> Behavior could be:
> 
>   * If a cherry-pick is in progress, show the patch corresponding to 
> `CHERRY_PICK_HEAD`.
>   * If no cherry-pick is in progress, report an appropriate error.
> 
> 
> Motivation
> 
> This would help users:
> 
>   * understand which commit caused the conflict
>   * review the exact changes being applied
>   * debug large range cherry-picks more easily
> 
> It would also provide feature parity with `git rebase`.
> 
> Best regards
> Florian
> 

> Hi Phillip,
> 
> thank you!
> Your reasoning makes sense, and therefore --show-current-patch is 
> probably a bad idea.
> I simply oversaw that complex sentence in the --help/manpage:
> 
>  >          2. The CHERRY_PICK_HEAD ref is set to point at the commit 
> that introduced the change that is difficult to apply.
> 
> Maybe adding "git show CHERRY_PICK_HEAD" to the Examples section of the 
> manpage improves finding it.

> Best regards
> Florian
> 
> Am 11.03.26 um 20:30 schrieb Phillip Wood:
>> Hi Florian
>>
>> On 11/03/2026 18:30, Florian Best wrote:
>>> Hello,
>>>
>>> When running `git cherry-pick` over a range of commits, the command 
>>> may stop due to conflicts. At that point Git reports the conflict but 
>>> does not provide an easy way to see which commit is currently being 
>>> cherry- picked or what patch is being applied.
>>>
>>> `git rebase` provides a helpful option for this situation:
>>>
>>> `git rebase --show-current-patch`
>>>
>>> This prints the patch of the commit that is currently being applied. 
>>> I believe a similar feature would be useful for `git cherry-pick`.
>>
>> That option exists for rebase because it originally applied a series 
>> of patches rather than performing a 3-way merge like cherry-pick and 
>> so there was no other way of seeing which commit was being processed. 
>> With cherry-pick you can use
>>
>>     git show CHERRY_PICK_HEAD
>>
>> which allows you to add any of the options that you'd use when showing 
>> a commit. That is more flexible than a "--show-current-patch" option 
>> because you can restrict the diff to the path that you are interested 
>> in, or show a word-diff etc. When reverting you can use REVERT_HEAD 
>> and when rebasing you can use REBASE_HEAD to see the commit being 
>> picked. I did wonder if the documentation could be improved but for 
>> cherry-pick it mentions CHERRY_PICK_HEAD in the description section at 
>> the top of the page.
>>
>> Thanks
>>
>> Phillip
>>
>>> Currently, when a conflict occurs during a range cherry-pick (e.g. 
>>> `git cherry-pick A..B`), there is no straightforward command to show 
>>> the patch of the commit being applied. While it is possible to 
>>> inspect `.git/CHERRY_PICK_HEAD`and run something like:
>>>
>>> `git show $(cat .git/CHERRY_PICK_HEAD)`
>>>
>>> this is not very discoverable and requires manual steps.
>>>
>>>
>>> Proposed feature
>>>
>>> Add a command:
>>>
>>> `git cherry-pick --show-current-patch`
>>>
>>> which would display the patch of the commit currently being applied 
>>> during an in-progress cherry-pick operation (similar to `git rebase 
>>> -- show-current-patch`).
>>>
>>> Behavior could be:
>>>
>>>   * If a cherry-pick is in progress, show the patch corresponding to 
>>> `CHERRY_PICK_HEAD`.
>>>   * If no cherry-pick is in progress, report an appropriate error.
>>>
>>>
>>> Motivation
>>>
>>> This would help users:
>>>
>>>   * understand which commit caused the conflict
>>>   * review the exact changes being applied
>>>   * debug large range cherry-picks more easily
>>>
>>> It would also provide feature parity with `git rebase`.
>>>
>>> Best regards
>>> Florian
>>>
>>
> 

> Hi Florian
>
> On 11/03/2026 19:42, Florian Best wrote:
>> Hi Phillip,
>>
>> thank you!
>> Your reasoning makes sense, and therefore --show-current-patch is 
>> probably a bad idea.
>> I simply oversaw that complex sentence in the --help/manpage:
>>
>>  >          2. The CHERRY_PICK_HEAD ref is set to point at the commit 
>> that introduced the change that is difficult to apply.
>>
>> Maybe adding "git show CHERRY_PICK_HEAD" to the Examples section of 
>> the manpage improves finding it.
>
> That sounds reasonable, are you interested in contributing a patch?
>
> Thanks
>
> Phillip
>
>> Best regards
>> Florian
>>
>> Am 11.03.26 um 20:30 schrieb Phillip Wood:
>>> Hi Florian
>>>
>>> On 11/03/2026 18:30, Florian Best wrote:
>>>> Hello,
>>>>
>>>> When running `git cherry-pick` over a range of commits, the command 
>>>> may stop due to conflicts. At that point Git reports the conflict 
>>>> but does not provide an easy way to see which commit is currently 
>>>> being cherry- picked or what patch is being applied.
>>>>
>>>> `git rebase` provides a helpful option for this situation:
>>>>
>>>> `git rebase --show-current-patch`
>>>>
>>>> This prints the patch of the commit that is currently being 
>>>> applied. I believe a similar feature would be useful for `git 
>>>> cherry-pick`.
>>>
>>> That option exists for rebase because it originally applied a series 
>>> of patches rather than performing a 3-way merge like cherry-pick and 
>>> so there was no other way of seeing which commit was being 
>>> processed. With cherry-pick you can use
>>>
>>>     git show CHERRY_PICK_HEAD
>>>
>>> which allows you to add any of the options that you'd use when 
>>> showing a commit. That is more flexible than a 
>>> "--show-current-patch" option because you can restrict the diff to 
>>> the path that you are interested in, or show a word-diff etc. When 
>>> reverting you can use REVERT_HEAD and when rebasing you can use 
>>> REBASE_HEAD to see the commit being picked. I did wonder if the 
>>> documentation could be improved but for cherry-pick it mentions 
>>> CHERRY_PICK_HEAD in the description section at the top of the page.
>>>
>>> Thanks
>>>
>>> Phillip
>>>
>>>> Currently, when a conflict occurs during a range cherry-pick (e.g. 
>>>> `git cherry-pick A..B`), there is no straightforward command to 
>>>> show the patch of the commit being applied. While it is possible to 
>>>> inspect `.git/CHERRY_PICK_HEAD`and run something like:
>>>>
>>>> `git show $(cat .git/CHERRY_PICK_HEAD)`
>>>>
>>>> this is not very discoverable and requires manual steps.
>>>>
>>>>
>>>> Proposed feature
>>>>
>>>> Add a command:
>>>>
>>>> `git cherry-pick --show-current-patch`
>>>>
>>>> which would display the patch of the commit currently being applied 
>>>> during an in-progress cherry-pick operation (similar to `git rebase 
>>>> -- show-current-patch`).
>>>>
>>>> Behavior could be:
>>>>
>>>>   * If a cherry-pick is in progress, show the patch corresponding 
>>>> to `CHERRY_PICK_HEAD`.
>>>>   * If no cherry-pick is in progress, report an appropriate error.
>>>>
>>>>
>>>> Motivation
>>>>
>>>> This would help users:
>>>>
>>>>   * understand which commit caused the conflict
>>>>   * review the exact changes being applied
>>>>   * debug large range cherry-picks more easily
>>>>
>>>> It would also provide feature parity with `git rebase`.
>>>>
>>>> Best regards
>>>> Florian
>>>>
>>>
>>
>