{"thread":{"id":"55125","subject":"how to most effectively cherry pick by selective patch hunk?","startedAt":"2021-02-09T14:36:29Z","lastAt":"2021-02-11T00:55:37Z","messageCount":5,"participants":["Robert P. J. Day","Jeff King","Andreas Schwab","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"416511","messageId":"566b38df-307c-f342-b583-3a50a81b5057@crashcourse.ca","threadId":"55125","inReplyTo":null,"subject":"how to most effectively cherry pick by selective patch hunk?","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2021-02-09T13:58:06Z","receivedAt":"2021-02-09T14:36:29Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"\n  (i'm looking for a solution not just for current git but, sadly,\ngoing back to git-2.9.2, which is installed on my current contract\nbuild system, and i have little authority to bump it up.)\n\n  summary: made a couple dozen commits on branch, call it \"oldb\",\nwhere i was relatively undisciplined about enforcing clean, modular\ncommits so i want to go back and clean things up -- refactor by\nchanging order, combining some trivial commits into one, breaking\nlarge, unwieldy commits into smaller pieces, better commit messages\nand so on, so i start a new branch \"newb\" at the same origin, and\nhere's the problem.\n\n  every old commit consisted of adding a new patch to an existing\nopenembedded recipe, so every commit had two components:\n\n  * a brand new patch file to be placed under \"files/\", and\n  * adding a new line to SRC_URI variable, as in:\n\n    SRC_URI += \" \\\n\tfirst.patch \\\n\tsecond.patch \\\n\tthird.patch \\\n\t... etc etc ...\n    \"\n\n  i think you see the problem. a commit adding a brand new file will\nnever create a merge conflict, as it's a new file. but if i start\nreordering commits, then the addition of that line to the .bbappend\nfile will *certainly* conflict as the patches will almost certainly be\nrenamed and in a different order.\n\n  what would be great is some sort of \"-p\" (patch selection) option\nwith cherry-pick, but i don't see that.\n\n  what would work for me is to auto-get the addition of the patch file\nfrom the old branch, at which point i am more than happy to manually\nfix the .bbappend file and manually do another commit. i'm thinking i\ncan just \"git checkout\" the new patch file from the old branch, and\ntake it from there.\n\n  thoughts? am i overthinking this?\n\nrday\n"},{"id":"416516","messageId":"YCK6w/VbfUtM68Ad@coredump.intra.peff.net","threadId":"55125","inReplyTo":"566b38df-307c-f342-b583-3a50a81b5057@crashcourse.ca","subject":"Re: how to most effectively cherry pick by selective patch hunk?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-02-09T16:39:31Z","receivedAt":"2021-02-09T16:40:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 09, 2021 at 08:58:06AM -0500, Robert P. J. Day wrote:\n\n>   what would be great is some sort of \"-p\" (patch selection) option\n> with cherry-pick, but i don't see that.\n\nWe have \"checkout -p\", but of course the problem there is that it's\npicking out of the whole state of that commit. So you might see other\nchanges not introduced by that commit.\n\nConceptually, adding \"cherry-pick -p\" would be pretty easy. The strategy\nfor all of the \"-p\" options is to generate a diff, then feed that diff\nto the patch-selection code, then apply whatever the user selects. For\n\"checkout -p $commit\", that diff is the diff between $commit and our\ncurrent state. But for \"cherry-pick -p\", it would be the diff between\n$commit^ and $commit.\n\nOf course that involves a change to Git, and you were looking for\nsomething you could do with existing versions. :) You can emulate it by\nmaking the commit's parent equivalent to your current state. I.e.:\n\n  git checkout --detach ;# detached HEAD for temporary commit\n  git cherry-pick $commit ;# maybe deal with conflicts\n  commit=$(git rev-parse --verify HEAD) ;# remember the temp commit\n  git checkout - ;# back to your branch\n  git checkout -p $commit\n\n-Peff\n"},{"id":"416520","messageId":"4fe5247a-96d6-c4a-97f8-9ede175adf90@crashcourse.ca","threadId":"55125","inReplyTo":"YCK6w/VbfUtM68Ad@coredump.intra.peff.net","subject":"Re: how to most effectively cherry pick by selective patch hunk?","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2021-02-09T16:58:10Z","receivedAt":"2021-02-09T16:59:02Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Tue, 9 Feb 2021, Jeff King wrote:\n\n> On Tue, Feb 09, 2021 at 08:58:06AM -0500, Robert P. J. Day wrote:\n>\n> >   what would be great is some sort of \"-p\" (patch selection) option\n> > with cherry-pick, but i don't see that.\n>\n> We have \"checkout -p\", but of course the problem there is that it's\n> picking out of the whole state of that commit. So you might see\n> other changes not introduced by that commit.\n\n  this is probably what i'll use since i can use <pathspec> to grab\nonly the patch file from that commit, then add and commit it manually\nfrom there.\n\nrday\n"},{"id":"416524","messageId":"87im712mi7.fsf@igel.home","threadId":"55125","inReplyTo":"YCK6w/VbfUtM68Ad@coredump.intra.peff.net","subject":"Re: how to most effectively cherry pick by selective patch hunk?","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2021-02-09T17:12:48Z","receivedAt":"2021-02-09T17:14:33Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Feb 09 2021, Jeff King wrote:\n\n> Of course that involves a change to Git, and you were looking for\n> something you could do with existing versions. :) You can emulate it by\n> making the commit's parent equivalent to your current state. I.e.:\n>\n>   git checkout --detach ;# detached HEAD for temporary commit\n>   git cherry-pick $commit ;# maybe deal with conflicts\n>   commit=$(git rev-parse --verify HEAD) ;# remember the temp commit\n>   git checkout - ;# back to your branch\n>   git checkout -p $commit\n\nAlternatively, you could cherry-pick normally, then use\n git checkout -p HEAD^\nto remove what you don't want.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"416686","messageId":"CABPp-BGKvsqQ3Xn_7Xi0GqxKS5qSdN6WyLYUXWWtzwdPqT_zTQ@mail.gmail.com","threadId":"55125","inReplyTo":"87im712mi7.fsf@igel.home","subject":"Re: how to most effectively cherry pick by selective patch hunk?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-02-11T00:54:15Z","receivedAt":"2021-02-11T00:55:37Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Feb 9, 2021 at 11:44 PM Andreas Schwab <schwab@linux-m68k.org> wrote:\n>\n> On Feb 09 2021, Jeff King wrote:\n>\n> > Of course that involves a change to Git, and you were looking for\n> > something you could do with existing versions. :) You can emulate it by\n> > making the commit's parent equivalent to your current state. I.e.:\n> >\n> >   git checkout --detach ;# detached HEAD for temporary commit\n> >   git cherry-pick $commit ;# maybe deal with conflicts\n> >   commit=$(git rev-parse --verify HEAD) ;# remember the temp commit\n> >   git checkout - ;# back to your branch\n> >   git checkout -p $commit\n>\n> Alternatively, you could cherry-pick normally, then use\n>  git checkout -p HEAD^\n> to remove what you don't want.\n\nOr, going into the slightly esoteric, you could define a custom local\nmerge driver for the particular file you want to ignore and say that\nmerges of that file always use the original version and ignore changes\nmade on both sides.\n\nman gitattributes(5), search for \"filfre\"\n\nAppears to be unchanged since git-2.5.0.\n\nOnly ever used them once myself long ago (and not for a real usecase),\nbecause I wanted to understand what they were for.  However, it seems\nlike they might be useful here.\n"}]}