From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Alejandro Colomar <alx@kernel.org>, git@vger.kernel.org
Subject: Re: git-cherry-pick(1) -- path
Date: Fri, 10 May 2024 10:03:31 -0700 [thread overview]
Message-ID: <xmqqcypt61lo.fsf@gitster.g> (raw)
In-Reply-To: <9b42e684-32e0-4372-8da6-40f9b708b6ca@gmail.com> (Phillip Wood's message of "Fri, 10 May 2024 11:00:31 +0100")
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.
next prev parent reply other threads:[~2024-05-10 17:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-09 22:32 git-cherry-pick(1) -- path Alejandro Colomar
2024-05-10 1:15 ` Junio C Hamano
2024-05-10 9:05 ` Alejandro Colomar
2024-05-10 10:00 ` Phillip Wood
2024-05-10 17:03 ` Junio C Hamano [this message]
2024-05-11 11:46 ` Alejandro Colomar
2024-05-11 15:01 ` Phillip Wood
2024-05-11 20:08 ` Alejandro Colomar
2024-05-12 15:35 ` Alejandro Colomar
2024-05-13 15:16 ` Phillip Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqcypt61lo.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=alx@kernel.org \
--cc=git@vger.kernel.org \
--cc=phillip.wood123@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).