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

From: Junio C Hamano <gitster@pobox.com>
Date: May 10, 2024, 17:03 UTC
Message-ID: <xmqqcypt61lo.fsf@gitster.g>
In-Reply-To: <9b42e684-32e0-4372-8da6-40f9b708b6ca@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 10 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.

Good thing to point out. "am -3" is just as good for this purpose and "almost clueless" is a derogatory comment that requires an apology ;-)

> 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.

If we were to use the ort machinery, it may not be too bad to use the pathspec only at the final writeout phase. That is, perform a full cherry-pick in the in-core index, reset all the entries in the in-core index back to HEAD that are outside the given pathspec, and then write out the result to the working tree. That way, an old change that was made to paths at the original location can be cherry picked to a much newer tree after these paths have been moved to a different location. Doing the same with the recursive machinery would be missier but perhaps the more recent merge-tree that uses the ort machinery to work purely in-core might be a good way to go.