Re: git-cherry-pick(1) -- path

From: Phillip Wood <phillip.wood123@gmail.com>
Date: May 10, 2024, 10:00 UTC
Message-ID: <9b42e684-32e0-4372-8da6-40f9b708b6ca@gmail.com>
In-Reply-To: <kk244kap6lhuvtfot55u4yb5k5eddwlzl4izlzqhe4pdj52cx7@slghmpvdswkt>

Hi Alex and Junio

On 10/05/2024 10:05, Alejandro Colomar wrote:

Show 10 quoted lines

> Hi Junio,
> 
> On Thu, May 09, 2024 at 06:15:24PM GMT, Junio C Hamano wrote:
>> Alejandro Colomar <alx@kernel.org> writes:
>>
>>> I'd be interested in being able to partially cherry-pick commits, based
>>> on a path filter (similar to how many other git(1) commands behave with
>>> -- path).
>>>
>>> Do you have any opinions on that?

I'd be happy to see a patch that adds that (I sometimes find myself wishing "git cherry-pick" had a "--patch" option to do something similar but that's a bit of a tangent here)

Show 7 quoted lines

>>      $ git format-patch --stdout -1 $ThatCommit -- $ThisPath |
>>        git am -3
> 
> Hmmm, I hadn't thought of that; very interesting!
> 
> Although I have some concerns with git-am(1); basically that it's almost
> clueless when there's a conflict.

"git am -3" should be fine here as you're guaranteed to have the necessary blobs available to create conflicts - this is what "git rebase --apply" does.

> If I find some time, I'll check if I can program that (although it would
> be the first time I do some contribution like that to git(1), so I may
> need some help).  :-)

As far as the implementation goes I haven't thought too deeply but I suspect we'd want to create a couple of trees based on the commit we want to cherry-pick and its parent filtered by the pathspec and use those in the tree-way merge with HEAD.

Best Wishes

Phillip