{"thread":{"id":"61448","subject":"git-cherry-pick(1) -- path","startedAt":"2024-05-09T22:32:33Z","lastAt":"2024-05-13T15:16:13Z","messageCount":10,"participants":["Alejandro Colomar","Junio C Hamano","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"494383","messageId":"e5pklmijfpbsnl2trj4n4czam7n7i37gx7w56med2pfaf6q3yx@wizseio2ickk","threadId":"61448","inReplyTo":null,"subject":"git-cherry-pick(1) -- path","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2024-05-09T22:32:30Z","receivedAt":"2024-05-09T22:32:33Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi!\n\nI'd be interested in being able to partially cherry-pick commits, based\non a path filter (similar to how many other git(1) commands behave with\n-- path).\n\nDo you have any opinions on that?\n\nHave a lovely night!\nAlex\n\n-- \n<https://www.alejandro-colomar.es/>\nA client is hiring kernel driver, mm, and/or crypto developers;\ncontact me if interested.\n"},{"id":"494386","messageId":"xmqqv83mqxg3.fsf@gitster.g","threadId":"61448","inReplyTo":"e5pklmijfpbsnl2trj4n4czam7n7i37gx7w56med2pfaf6q3yx@wizseio2ickk","subject":"Re: git-cherry-pick(1) -- path","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-05-10T01:15:24Z","receivedAt":"2024-05-10T01:15:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alejandro Colomar <alx@kernel.org> writes:\n\n> I'd be interested in being able to partially cherry-pick commits, based\n> on a path filter (similar to how many other git(1) commands behave with\n> -- path).\n>\n> Do you have any opinions on that?\n\nOpinions?  \n\nPersonally it is a \"Meh\" for me, because I would instead do\n\n    $ git format-patch --stdout -1 $ThatCommit -- $ThisPath |\n      git am -3\n\nwhich would be mostly sufficient for my purpose, but I do not see\nany fundamental reason why it should not exist.\n\nIt is already well known that future merges from the same branch\nwill have to deal with duplicated changes brought in by picking\ncommits with \"git cherry-pick\".  Having a pathspec-limited variant\nof \"git cherry-pick\" would not make the world a worse place.\n"},{"id":"494411","messageId":"kk244kap6lhuvtfot55u4yb5k5eddwlzl4izlzqhe4pdj52cx7@slghmpvdswkt","threadId":"61448","inReplyTo":"xmqqv83mqxg3.fsf@gitster.g","subject":"Re: git-cherry-pick(1) -- path","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2024-05-10T09:05:29Z","receivedAt":"2024-05-10T09:05:32Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi Junio,\n\nOn Thu, May 09, 2024 at 06:15:24PM GMT, Junio C Hamano wrote:\n> Alejandro Colomar <alx@kernel.org> writes:\n> \n> > I'd be interested in being able to partially cherry-pick commits, based\n> > on a path filter (similar to how many other git(1) commands behave with\n> > -- path).\n> >\n> > Do you have any opinions on that?\n> \n> Opinions?  \n> \n> Personally it is a \"Meh\" for me, because I would instead do\n> \n>     $ git format-patch --stdout -1 $ThatCommit -- $ThisPath |\n>       git am -3\n\nHmmm, I hadn't thought of that; very interesting!\n\nAlthough I have some concerns with git-am(1); basically that it's almost\nclueless when there's a conflict.  With git-cherry-pick(1), at least I\nhave the ability to resolve the conflict manually.\n\nIf I find some time, I'll check if I can program that (although it would\nbe the first time I do some contribution like that to git(1), so I may\nneed some help).  :-)\n\nHave a lovely day!\nAlex\n\n> which would be mostly sufficient for my purpose, but I do not see\n> any fundamental reason why it should not exist.\n> \n> It is already well known that future merges from the same branch\n> will have to deal with duplicated changes brought in by picking\n> commits with \"git cherry-pick\".  Having a pathspec-limited variant\n> of \"git cherry-pick\" would not make the world a worse place.\n\n-- \n<https://www.alejandro-colomar.es/>\n"},{"id":"494418","messageId":"9b42e684-32e0-4372-8da6-40f9b708b6ca@gmail.com","threadId":"61448","inReplyTo":"kk244kap6lhuvtfot55u4yb5k5eddwlzl4izlzqhe4pdj52cx7@slghmpvdswkt","subject":"Re: git-cherry-pick(1) -- path","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-05-10T10:00:31Z","receivedAt":"2024-05-10T10:00:33Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Alex and Junio\n\nOn 10/05/2024 10:05, Alejandro Colomar wrote:\n> Hi Junio,\n> \n> On Thu, May 09, 2024 at 06:15:24PM GMT, Junio C Hamano wrote:\n>> Alejandro Colomar <alx@kernel.org> writes:\n>>\n>>> I'd be interested in being able to partially cherry-pick commits, based\n>>> on a path filter (similar to how many other git(1) commands behave with\n>>> -- path).\n>>>\n>>> Do you have any opinions on that?\nI'd be happy to see a patch that adds that (I sometimes find myself \nwishing \"git cherry-pick\" had a \"--patch\" option to do something similar \nbut that's a bit of a tangent here)\n\n>>      $ git format-patch --stdout -1 $ThatCommit -- $ThisPath |\n>>        git am -3\n> \n> Hmmm, I hadn't thought of that; very interesting!\n> \n> Although I have some concerns with git-am(1); basically that it's almost\n> clueless when there's a conflict.\n\n\"git am -3\" should be fine here as you're guaranteed to have the \nnecessary blobs available to create conflicts - this is what \"git rebase \n--apply\" does.\n\n> If I find some time, I'll check if I can program that (although it would\n> be the first time I do some contribution like that to git(1), so I may\n> need some help).  :-)\n\nAs far as the implementation goes I haven't thought too deeply but I \nsuspect we'd want to create a couple of trees based on the commit we \nwant to cherry-pick and its parent filtered by the pathspec and use \nthose in the tree-way merge with HEAD.\n\nBest Wishes\n\nPhillip\n"},{"id":"494480","messageId":"xmqqcypt61lo.fsf@gitster.g","threadId":"61448","inReplyTo":"9b42e684-32e0-4372-8da6-40f9b708b6ca@gmail.com","subject":"Re: git-cherry-pick(1) -- path","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-05-10T17:03:31Z","receivedAt":"2024-05-10T17:03:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood <phillip.wood123@gmail.com> writes:\n\n>>>      $ git format-patch --stdout -1 $ThatCommit -- $ThisPath |\n>>>        git am -3\n>> Hmmm, I hadn't thought of that; very interesting!\n>> Although I have some concerns with git-am(1); basically that it's\n>> almost\n>> clueless when there's a conflict.\n>\n> \"git am -3\" should be fine here as you're guaranteed to have the\n> necessary blobs available to create conflicts - this is what \"git\n> rebase --apply\" does.\n\nGood thing to point out.  \"am -3\" is just as good for this purpose\nand \"almost clueless\" is a derogatory comment that requires an\napology ;-)\n\n> As far as the implementation goes I haven't thought too deeply but I\n> suspect we'd want to create a couple of trees based on the commit we\n> want to cherry-pick and its parent filtered by the pathspec and use\n> those in the tree-way merge with HEAD.\n\nIf we were to use the ort machinery, it may not be too bad to use\nthe pathspec only at the final writeout phase.  That is, perform a\nfull cherry-pick in the in-core index, reset all the entries in the\nin-core index back to HEAD that are outside the given pathspec, and\nthen write out the result to the working tree.  That way, an old\nchange that was made to paths at the original location can be cherry\npicked to a much newer tree after these paths have been moved to a\ndifferent location.  Doing the same with the recursive machinery\nwould be missier but perhaps the more recent merge-tree that uses\nthe ort machinery to work purely in-core might be a good way to go.\n\n\n\n\n"},{"id":"494531","messageId":"bpjfsabhstkbuvo6ksj3owoxvutgquripmqmqi63ykaquhky2u@r7mfrwucgnye","threadId":"61448","inReplyTo":"xmqqcypt61lo.fsf@gitster.g","subject":"Re: git-cherry-pick(1) -- path","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2024-05-11T11:46:57Z","receivedAt":"2024-05-11T11:47:01Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi Phillip, Junio,\n\nOn Fri, May 10, 2024 at 10:03:31AM GMT, Junio C Hamano wrote:\n> Phillip Wood <phillip.wood123@gmail.com> writes:\n> \n> >>>      $ git format-patch --stdout -1 $ThatCommit -- $ThisPath |\n> >>>        git am -3\n> >> Hmmm, I hadn't thought of that; very interesting!\n> >> Although I have some concerns with git-am(1); basically that it's\n> >> almost\n> >> clueless when there's a conflict.\n> >\n> > \"git am -3\" should be fine here as you're guaranteed to have the\n> > necessary blobs available to create conflicts - this is what \"git\n> > rebase --apply\" does.\n> \n> Good thing to point out.  \"am -3\" is just as good for this purpose\n> and \"almost clueless\" is a derogatory comment that requires an\n> apology ;-)\n\nHuh, I am quite surprised by `git am -3`.  I've tried it just now, and\nit's amazing.  I certainly must apologize.  :-)\n\nI tried it yesterday, but the patches were from a different repo, and\nnot available locally, so it really didn't do anything.  But now I tried\nit within the same repo, and it's really nice!\n\n> > As far as the implementation goes I haven't thought too deeply but I\n> > suspect we'd want to create a couple of trees based on the commit we\n> > want to cherry-pick and its parent filtered by the pathspec and use\n> > those in the tree-way merge with HEAD.\n> \n> If we were to use the ort machinery, it may not be too bad to use\n> the pathspec only at the final writeout phase.  That is, perform a\n> full cherry-pick in the in-core index, reset all the entries in the\n> in-core index back to HEAD that are outside the given pathspec, and\n> then write out the result to the working tree.  That way, an old\n> change that was made to paths at the original location can be cherry\n> picked to a much newer tree after these paths have been moved to a\n> different location.  Doing the same with the recursive machinery\n> would be missier but perhaps the more recent merge-tree that uses\n> the ort machinery to work purely in-core might be a good way to go.\n\nI didn't understand the last part well, but I guess I may do when I\nstart researching into it.  :)\n\nApart from <builtin/revert.c>, do you recommend I look into any\nparticular files?\n\nThanks!\n\nAnd have a lovely weekend!\nAlex\n\n\n-- \n<https://www.alejandro-colomar.es/>\nA client is hiring kernel driver, mm, and/or crypto developers;\ncontact me if interested.\n"},{"id":"494538","messageId":"3a48b2fe-78c0-41f4-9e60-4146f15dfa97@gmail.com","threadId":"61448","inReplyTo":"bpjfsabhstkbuvo6ksj3owoxvutgquripmqmqi63ykaquhky2u@r7mfrwucgnye","subject":"Re: git-cherry-pick(1) -- path","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-05-11T15:01:18Z","receivedAt":"2024-05-11T15:01:21Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Alex and Junio\n\nOn 11/05/2024 12:46, Alejandro Colomar wrote:\n> Hi Phillip, Junio,\n> \n> On Fri, May 10, 2024 at 10:03:31AM GMT, Junio C Hamano wrote:\n>> Phillip Wood <phillip.wood123@gmail.com> writes:\n>>\n>>>>>       $ git format-patch --stdout -1 $ThatCommit -- $ThisPath |\n>>>>>         git am -3\n>>>> Hmmm, I hadn't thought of that; very interesting!\n>>>> Although I have some concerns with git-am(1); basically that it's\n>>>> almost\n>>>> clueless when there's a conflict.\n>>>\n>>> \"git am -3\" should be fine here as you're guaranteed to have the\n>>> necessary blobs available to create conflicts - this is what \"git\n>>> rebase --apply\" does.\n>>\n>> Good thing to point out.  \"am -3\" is just as good for this purpose\n>> and \"almost clueless\" is a derogatory comment that requires an\n>> apology ;-)\n> \n> Huh, I am quite surprised by `git am -3`.  I've tried it just now, and\n> it's amazing.  I certainly must apologize.  :-)\n> \n> I tried it yesterday, but the patches were from a different repo, and\n> not available locally, so it really didn't do anything.  But now I tried\n> it within the same repo, and it's really nice!\n> \n>>> As far as the implementation goes I haven't thought too deeply but I\n>>> suspect we'd want to create a couple of trees based on the commit we\n>>> want to cherry-pick and its parent filtered by the pathspec and use\n>>> those in the tree-way merge with HEAD.\n>>\n>> If we were to use the ort machinery, it may not be too bad to use\n>> the pathspec only at the final writeout phase.\n\nThat would be tempting if cherry-pick didn't have a \"--strategy\" option. \nI think we need something more generic to cope with that.\n\n>>  That is, perform a\n>> full cherry-pick in the in-core index, reset all the entries in the\n>> in-core index back to HEAD that are outside the given pathspec, and\n>> then write out the result to the working tree.  That way, an old\n>> change that was made to paths at the original location can be cherry\n>> picked to a much newer tree after these paths have been moved to a\n>> different location.  Doing the same with the recursive machinery\n>> would be missier but perhaps the more recent merge-tree that uses\n>> the ort machinery to work purely in-core might be a good way to go.\n\nMy hope was that the changes required to create a couple of new trees \nthat are then used instead of the original commits when a pathspec is \ngiven would be fairly localized.\n\n> I didn't understand the last part well, but I guess I may do when I\n> start researching into it.  :)\n> \n> Apart from <builtin/revert.c>, do you recommend I look into any\n> particular files?\n\nsequencer.c. If we go for the \"write new trees and use those in the \nmerge\" approach then we'd need to change do_pick_commit() to create the \ntrees and we'd probably want to change do_recursive_merge() to take \ntrees rather than commits. We'd also need to add a new pathspec member \nto struct replay_opts to pass the pathspec around.\n\nBest Wishes\n\nPhillip\n"},{"id":"494545","messageId":"fz7tgtvp6qp7h3vcaviibn3rktkwg5q4qjeuvmciejqn2m7uow@3o5hi6hdbkt5","threadId":"61448","inReplyTo":"3a48b2fe-78c0-41f4-9e60-4146f15dfa97@gmail.com","subject":"Re: git-cherry-pick(1) -- path","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2024-05-11T20:08:44Z","receivedAt":"2024-05-11T20:08:47Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi Phillip,\n\nOn Sat, May 11, 2024 at 04:01:18PM GMT, Phillip Wood wrote:\n> sequencer.c. If we go for the \"write new trees and use those in the merge\"\n> approach then we'd need to change do_pick_commit() to create the trees and\n> we'd probably want to change do_recursive_merge() to take trees rather than\n> commits. We'd also need to add a new pathspec member to struct replay_opts\n> to pass the pathspec around.\n\nI've been thinking this evening that since\n`git format-patch ... | git am -3` works so well, and since the behavior\nof cherry-pick -- path isn't so obvious (we're discussing different\nstrategies), maybe we should just not do it.  I fell in love with am -3.\n\n:-3\n\nHave a lovely night!\nAlex\n\n-- \n<https://www.alejandro-colomar.es/>\nA client is hiring kernel driver, mm, and/or crypto developers;\ncontact me if interested.\n"},{"id":"494559","messageId":"xnzks3eybwx5lj7vnf66pfacjvcn4anhgfe7fx3ljvtysxpsrv@tt2wvkwezh3l","threadId":"61448","inReplyTo":"fz7tgtvp6qp7h3vcaviibn3rktkwg5q4qjeuvmciejqn2m7uow@3o5hi6hdbkt5","subject":"Re: git-cherry-pick(1) -- path","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2024-05-12T15:35:02Z","receivedAt":"2024-05-12T15:35:05Z","isPatch":false,"sender":{"key":"alx@kernel.org","avatar":null},"body":"Hi,\n\nOn Sat, May 11, 2024 at 10:08:47PM GMT, Alejandro Colomar wrote:\n> Hi Phillip,\n> \n> On Sat, May 11, 2024 at 04:01:18PM GMT, Phillip Wood wrote:\n> > sequencer.c. If we go for the \"write new trees and use those in the merge\"\n> > approach then we'd need to change do_pick_commit() to create the trees and\n> > we'd probably want to change do_recursive_merge() to take trees rather than\n> > commits. We'd also need to add a new pathspec member to struct replay_opts\n> > to pass the pathspec around.\n> \n> I've been thinking this evening that since\n> `git format-patch ... | git am -3` works so well, and since the behavior\n> of cherry-pick -- path isn't so obvious (we're discussing different\n> strategies), maybe we should just not do it.  I fell in love with am -3.\n\nIn the end, I'm using the following:\n\n$ git log --oneline 2024a..tz/main -- tzfile.5 tzselect.8 zic.8 zdump.8 \\\n| awk '{print $1}' \\\n| tac \\\n| while read c; do\n\tgit format-patch --stdout -1 $c -- tzfile.5 tzselect.8 z*.8 \\\n\t| sed '/^---$/s/^/\\n/' \\\n\t| sed \"/^---$/i Cherry-picked-from: tz.git $( \\\n\t\t\tgit log -1 --oneline --abbrev=12 $c \\\n\t\t\t| awk '{print $1}' \\\n\t\t) (\\\"$( \\\n\t\t\tgit log -1 --oneline $c \\\n\t\t\t| sed 's/[^ ]* //' \\\n\t\t)\\\")\";\ndone \\\n| git am -3 -s;\n\n\nAnd it works like a charm.  If I had to spell that as a\ngit-cherry-pick(1) command, I'd say\n`git cherry-pick -x -s 2024a..tz/main -- tzfile.5 tzselect.8 zic.8 zdump.8`\n\nBTW, there's something I noticed when I had an accident (forgot to\ntac(1) the commit list): the git-am(1) conflicts session isn't as good\nas a cherry-pick one: it doesn't show which commits are being applied.\nIf you're in the middle of a 50-commit cherry-pick, it's hard to see\nwhere it's going wrong.  So maybe adding this functionallity to\ngit-cherry-pick(1) could be a good thing.\n\nHave a lovely day!\nAlex\n\n-- \n<https://www.alejandro-colomar.es/>\n"},{"id":"494634","messageId":"6519a197-76be-4723-be27-b9a5cd75731a@gmail.com","threadId":"61448","inReplyTo":"fz7tgtvp6qp7h3vcaviibn3rktkwg5q4qjeuvmciejqn2m7uow@3o5hi6hdbkt5","subject":"Re: git-cherry-pick(1) -- path","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-05-13T15:16:07Z","receivedAt":"2024-05-13T15:16:13Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Alex\n\nOn 11/05/2024 21:08, Alejandro Colomar wrote:\n> I've been thinking this evening that since\n> `git format-patch ... | git am -3` works so well, and since the behavior\n> of cherry-pick -- path isn't so obvious (we're discussing different\n> strategies), maybe we should just not do it.  I fell in love with am -3.\n\nI agree that using \"format-patch\" and \"am\" is a good enough solution\n\nThanks\n\nPhillip\n"}]}