* git-cherry-pick(1) -- path @ 2024-05-09 22:32 Alejandro Colomar 2024-05-10 1:15 ` Junio C Hamano 0 siblings, 1 reply; 10+ messages in thread From: Alejandro Colomar @ 2024-05-09 22:32 UTC (permalink / raw) To: git [-- Attachment #1: Type: text/plain, Size: 367 bytes --] Hi! I'd be interested in being able to partially cherry-pick commits, based on a path filter (similar to how many other git(1) commands behave with -- path). Do you have any opinions on that? Have a lovely night! Alex -- <https://www.alejandro-colomar.es/> A client is hiring kernel driver, mm, and/or crypto developers; contact me if interested. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git-cherry-pick(1) -- path 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 0 siblings, 1 reply; 10+ messages in thread From: Junio C Hamano @ 2024-05-10 1:15 UTC (permalink / raw) To: Alejandro Colomar; +Cc: git Alejandro Colomar <alx@kernel.org> writes: > I'd be interested in being able to partially cherry-pick commits, based > on a path filter (similar to how many other git(1) commands behave with > -- path). > > Do you have any opinions on that? Opinions? Personally it is a "Meh" for me, because I would instead do $ git format-patch --stdout -1 $ThatCommit -- $ThisPath | git am -3 which would be mostly sufficient for my purpose, but I do not see any fundamental reason why it should not exist. It is already well known that future merges from the same branch will have to deal with duplicated changes brought in by picking commits with "git cherry-pick". Having a pathspec-limited variant of "git cherry-pick" would not make the world a worse place. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git-cherry-pick(1) -- path 2024-05-10 1:15 ` Junio C Hamano @ 2024-05-10 9:05 ` Alejandro Colomar 2024-05-10 10:00 ` Phillip Wood 0 siblings, 1 reply; 10+ messages in thread From: Alejandro Colomar @ 2024-05-10 9:05 UTC (permalink / raw) To: Junio C Hamano; +Cc: git [-- Attachment #1: Type: text/plain, Size: 1404 bytes --] Hi Junio, On Thu, May 09, 2024 at 06:15:24PM GMT, Junio C Hamano wrote: > Alejandro Colomar <alx@kernel.org> writes: > > > I'd be interested in being able to partially cherry-pick commits, based > > on a path filter (similar to how many other git(1) commands behave with > > -- path). > > > > Do you have any opinions on that? > > Opinions? > > Personally it is a "Meh" for me, because I would instead do > > $ 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. With git-cherry-pick(1), at least I have the ability to resolve the conflict manually. If I find some time, I'll check if I can program that (although it would be the first time I do some contribution like that to git(1), so I may need some help). :-) Have a lovely day! Alex > which would be mostly sufficient for my purpose, but I do not see > any fundamental reason why it should not exist. > > It is already well known that future merges from the same branch > will have to deal with duplicated changes brought in by picking > commits with "git cherry-pick". Having a pathspec-limited variant > of "git cherry-pick" would not make the world a worse place. -- <https://www.alejandro-colomar.es/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git-cherry-pick(1) -- path 2024-05-10 9:05 ` Alejandro Colomar @ 2024-05-10 10:00 ` Phillip Wood 2024-05-10 17:03 ` Junio C Hamano 0 siblings, 1 reply; 10+ messages in thread From: Phillip Wood @ 2024-05-10 10:00 UTC (permalink / raw) To: Alejandro Colomar, Junio C Hamano; +Cc: git Hi Alex and Junio On 10/05/2024 10:05, Alejandro Colomar wrote: > Hi Junio, > > On Thu, May 09, 2024 at 06:15:24PM GMT, Junio C Hamano wrote: >> Alejandro Colomar <alx@kernel.org> writes: >> >>> I'd be interested in being able to partially cherry-pick commits, based >>> on a path filter (similar to how many other git(1) commands behave with >>> -- path). >>> >>> Do you have any opinions on that? I'd be happy to see a patch that adds that (I sometimes find myself wishing "git cherry-pick" had a "--patch" option to do something similar but that's a bit of a tangent here) >> $ 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. > If I find some time, I'll check if I can program that (although it would > be the first time I do some contribution like that to git(1), so I may > need some help). :-) 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. Best Wishes Phillip ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git-cherry-pick(1) -- path 2024-05-10 10:00 ` Phillip Wood @ 2024-05-10 17:03 ` Junio C Hamano 2024-05-11 11:46 ` Alejandro Colomar 0 siblings, 1 reply; 10+ messages in thread From: Junio C Hamano @ 2024-05-10 17:03 UTC (permalink / raw) To: Phillip Wood; +Cc: Alejandro Colomar, git 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git-cherry-pick(1) -- path 2024-05-10 17:03 ` Junio C Hamano @ 2024-05-11 11:46 ` Alejandro Colomar 2024-05-11 15:01 ` Phillip Wood 0 siblings, 1 reply; 10+ messages in thread From: Alejandro Colomar @ 2024-05-11 11:46 UTC (permalink / raw) To: Junio C Hamano; +Cc: Phillip Wood, git [-- Attachment #1: Type: text/plain, Size: 2406 bytes --] Hi Phillip, Junio, On Fri, May 10, 2024 at 10:03:31AM GMT, Junio C Hamano wrote: > 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 ;-) Huh, I am quite surprised by `git am -3`. I've tried it just now, and it's amazing. I certainly must apologize. :-) I tried it yesterday, but the patches were from a different repo, and not available locally, so it really didn't do anything. But now I tried it within the same repo, and it's really nice! > > 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. I didn't understand the last part well, but I guess I may do when I start researching into it. :) Apart from <builtin/revert.c>, do you recommend I look into any particular files? Thanks! And have a lovely weekend! Alex -- <https://www.alejandro-colomar.es/> A client is hiring kernel driver, mm, and/or crypto developers; contact me if interested. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git-cherry-pick(1) -- path 2024-05-11 11:46 ` Alejandro Colomar @ 2024-05-11 15:01 ` Phillip Wood 2024-05-11 20:08 ` Alejandro Colomar 0 siblings, 1 reply; 10+ messages in thread From: Phillip Wood @ 2024-05-11 15:01 UTC (permalink / raw) To: Alejandro Colomar, Junio C Hamano; +Cc: git Hi Alex and Junio On 11/05/2024 12:46, Alejandro Colomar wrote: > Hi Phillip, Junio, > > On Fri, May 10, 2024 at 10:03:31AM GMT, Junio C Hamano wrote: >> 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 ;-) > > Huh, I am quite surprised by `git am -3`. I've tried it just now, and > it's amazing. I certainly must apologize. :-) > > I tried it yesterday, but the patches were from a different repo, and > not available locally, so it really didn't do anything. But now I tried > it within the same repo, and it's really nice! > >>> 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 would be tempting if cherry-pick didn't have a "--strategy" option. I think we need something more generic to cope with that. >> 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. My hope was that the changes required to create a couple of new trees that are then used instead of the original commits when a pathspec is given would be fairly localized. > I didn't understand the last part well, but I guess I may do when I > start researching into it. :) > > Apart from <builtin/revert.c>, do you recommend I look into any > particular files? sequencer.c. If we go for the "write new trees and use those in the merge" approach then we'd need to change do_pick_commit() to create the trees and we'd probably want to change do_recursive_merge() to take trees rather than commits. We'd also need to add a new pathspec member to struct replay_opts to pass the pathspec around. Best Wishes Phillip ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git-cherry-pick(1) -- path 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 0 siblings, 2 replies; 10+ messages in thread From: Alejandro Colomar @ 2024-05-11 20:08 UTC (permalink / raw) To: phillip.wood; +Cc: Junio C Hamano, git [-- Attachment #1: Type: text/plain, Size: 857 bytes --] Hi Phillip, On Sat, May 11, 2024 at 04:01:18PM GMT, Phillip Wood wrote: > sequencer.c. If we go for the "write new trees and use those in the merge" > approach then we'd need to change do_pick_commit() to create the trees and > we'd probably want to change do_recursive_merge() to take trees rather than > commits. We'd also need to add a new pathspec member to struct replay_opts > to pass the pathspec around. I've been thinking this evening that since `git format-patch ... | git am -3` works so well, and since the behavior of cherry-pick -- path isn't so obvious (we're discussing different strategies), maybe we should just not do it. I fell in love with am -3. :-3 Have a lovely night! Alex -- <https://www.alejandro-colomar.es/> A client is hiring kernel driver, mm, and/or crypto developers; contact me if interested. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git-cherry-pick(1) -- path 2024-05-11 20:08 ` Alejandro Colomar @ 2024-05-12 15:35 ` Alejandro Colomar 2024-05-13 15:16 ` Phillip Wood 1 sibling, 0 replies; 10+ messages in thread From: Alejandro Colomar @ 2024-05-12 15:35 UTC (permalink / raw) To: phillip.wood; +Cc: Junio C Hamano, git [-- Attachment #1: Type: text/plain, Size: 1901 bytes --] Hi, On Sat, May 11, 2024 at 10:08:47PM GMT, Alejandro Colomar wrote: > Hi Phillip, > > On Sat, May 11, 2024 at 04:01:18PM GMT, Phillip Wood wrote: > > sequencer.c. If we go for the "write new trees and use those in the merge" > > approach then we'd need to change do_pick_commit() to create the trees and > > we'd probably want to change do_recursive_merge() to take trees rather than > > commits. We'd also need to add a new pathspec member to struct replay_opts > > to pass the pathspec around. > > I've been thinking this evening that since > `git format-patch ... | git am -3` works so well, and since the behavior > of cherry-pick -- path isn't so obvious (we're discussing different > strategies), maybe we should just not do it. I fell in love with am -3. In the end, I'm using the following: $ git log --oneline 2024a..tz/main -- tzfile.5 tzselect.8 zic.8 zdump.8 \ | awk '{print $1}' \ | tac \ | while read c; do git format-patch --stdout -1 $c -- tzfile.5 tzselect.8 z*.8 \ | sed '/^---$/s/^/\n/' \ | sed "/^---$/i Cherry-picked-from: tz.git $( \ git log -1 --oneline --abbrev=12 $c \ | awk '{print $1}' \ ) (\"$( \ git log -1 --oneline $c \ | sed 's/[^ ]* //' \ )\")"; done \ | git am -3 -s; And it works like a charm. If I had to spell that as a git-cherry-pick(1) command, I'd say `git cherry-pick -x -s 2024a..tz/main -- tzfile.5 tzselect.8 zic.8 zdump.8` BTW, there's something I noticed when I had an accident (forgot to tac(1) the commit list): the git-am(1) conflicts session isn't as good as a cherry-pick one: it doesn't show which commits are being applied. If you're in the middle of a 50-commit cherry-pick, it's hard to see where it's going wrong. So maybe adding this functionallity to git-cherry-pick(1) could be a good thing. Have a lovely day! Alex -- <https://www.alejandro-colomar.es/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git-cherry-pick(1) -- path 2024-05-11 20:08 ` Alejandro Colomar 2024-05-12 15:35 ` Alejandro Colomar @ 2024-05-13 15:16 ` Phillip Wood 1 sibling, 0 replies; 10+ messages in thread From: Phillip Wood @ 2024-05-13 15:16 UTC (permalink / raw) To: Alejandro Colomar, phillip.wood; +Cc: Junio C Hamano, git Hi Alex On 11/05/2024 21:08, Alejandro Colomar wrote: > I've been thinking this evening that since > `git format-patch ... | git am -3` works so well, and since the behavior > of cherry-pick -- path isn't so obvious (we're discussing different > strategies), maybe we should just not do it. I fell in love with am -3. I agree that using "format-patch" and "am" is a good enough solution Thanks Phillip ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-05-13 15:16 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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).