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

[Junio C Hamano <gitster@pobox.com>]

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

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