{"thread":{"id":"64225","subject":"customizing \"cherry picked from commit abcd\" comment","startedAt":"2025-09-29T12:10:39Z","lastAt":"2025-10-03T11:42:00Z","messageCount":7,"participants":["Rasmus Villemoes","Oswald Buddenhagen","brian m. carlson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"527584","messageId":"87v7l18nnt.fsf@prevas.dk","threadId":"64225","inReplyTo":null,"subject":"customizing \"cherry picked from commit abcd\" comment","fromName":"Rasmus Villemoes","fromEmail":"ravi@prevas.dk","sentAt":"2025-09-29T12:10:30Z","receivedAt":"2025-09-29T12:10:39Z","isPatch":false,"sender":{"key":"ravi@prevas.dk","avatar":null},"body":"Hi,\n\nWhen working on a custom U-Boot or linux kernel based of some vX.Y, I often end up\ncherry-picking fixes from upstream. Using \"cherry-pick -x\" is nice, but\nI usually amend the commit so that it doesn't just say\n\n (cherry picked from commit bfbbd8472edbcff1f530ef8e1d74c56af74ecf13)\n\nbut instead\n\n (cherry picked from commit bfbbd8472edbcff1f530ef8e1d74c56af74ecf13 aka v2025.01-rc2~35^2~5)\n\nThis makes it easier, when porting to v+1, to know if that commit still\nneeds to be cherry-picked or is already included, and also makes it\nobvious to anyone reading the current history to know the \"upstream\nstatus\" of that commit.\n\nNow editing in that, which I get from \"git describe --contains\n--match=v*\", is not too onerous, but I'd still like a way to automate\nit. What I imagine is some config knob indicating an executable to call\nwith a single argument, the full sha1 of the cherry-picked commit, and\nusing that executable's stdout in lieu of the default -x message.\n\nOf course, it's quite possible that the script cannot find anything\nmeaningful to say. So one would have to define what it means if it\nprints nothing on stdout, and/or what it means if it exits\nunsuccessfully. I'm leaning on saying \"exit 0 => use stdout as-is, even\nif empty; exit != 0 => fail the cherry pick operation\", but I can\ncertainly be convinced that some other behaviour is more sensible,\ne.g. having some combination indicate \"fall back to the default\nmessage\".\n\nIs this something that others could find useful, or is it too niche? If\nthe former, I'll try to cook up a patch, but I'd also like some input on\nwhat the semantics should be, or if there's some other idea for\nachieving the same thing without a custom callback.\n\nRasmus\n"},{"id":"527625","messageId":"aNus0ulSTb4rAYdF@ugly.lan","threadId":"64225","inReplyTo":"87v7l18nnt.fsf@prevas.dk","subject":"Re: customizing \"cherry picked from commit abcd\" comment","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2025-09-30T10:11:30Z","receivedAt":"2025-09-30T10:11:32Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Mon, Sep 29, 2025 at 02:10:30PM +0200, Rasmus Villemoes wrote:\n>This makes it easier, when porting to v+1, to know if that commit still\n>needs to be cherry-picked or is already included, and also makes it\n>obvious to anyone reading the current history to know the \"upstream\n>status\" of that commit.\n>\ni sometimes customize this pseudo-footer as well, but it's usually \nthings like \"(partially cherry-picked ...)\" or \"(... from \n/)\", etc.\n\nyour particular use case would imo be better addressed by implementing \nbi-directional linking between picked commits via a standardized \ngit-notes namespace.\n\nthe pseudo-trailer is really just a hack in the first place, and afaict \nthat status quo results from an ideological commitment against \ncherry-picks during the early history of git. but it's really kinda \nsilly that subversion and perforce have better tracking of cherry-picks \nto this date, even when it's their only way to do merges.\n"},{"id":"527639","messageId":"aNv0glRxXcviP5yH@fruit.crustytoothpaste.net","threadId":"64225","inReplyTo":"87v7l18nnt.fsf@prevas.dk","subject":"Re: customizing \"cherry picked from commit abcd\" comment","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-09-30T15:17:22Z","receivedAt":"2025-09-30T15:17:24Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-09-29 at 12:10:30, Rasmus Villemoes wrote:\n> Is this something that others could find useful, or is it too niche? If\n> the former, I'll try to cook up a patch, but I'd also like some input on\n> what the semantics should be, or if there's some other idea for\n> achieving the same thing without a custom callback.\n\nI haven't looked, but I wonder if maybe you can use one of the commit\nmessage hooks for this. If you're creating that cherry pick, then you\nmight be able to automatically edit the message accordingly using some\nsort of script.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"527642","messageId":"xmqq5xd054r2.fsf@gitster.g","threadId":"64225","inReplyTo":"aNus0ulSTb4rAYdF@ugly.lan","subject":"Re: customizing \"cherry picked from commit abcd\" comment","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-09-30T15:39:29Z","receivedAt":"2025-09-30T15:39:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Oswald Buddenhagen writes:\n\n> i sometimes customize this pseudo-footer as well, but it's usually\n> things like \"(partially cherry-picked ...)\" or \"(... from\n> /)\", etc.\n\nThat does sound a sensible thing to do, assuming that the original\ncommit is public. See below for a backstory why it is only a commit\nobject name and nothing else.\n\n> your particular use case would imo be better addressed by implementing\n> bi-directional linking between picked commits via a standardized\n> git-notes namespace.\n\nA nice property of notes is that they can be added after the fact\nand can be mde bidirectional, so in a workflow allows adopting this\ngreat suggestion, it is a very sensible thing to do.\n\n> the pseudo-trailer is really just a hack in the first place, and\n> afaict that status quo results from an ideological commitment against\n> cherry-picks during the early history of git. but it's really kinda\n> silly that subversion and perforce have better tracking of\n> cherry-picks to this date, even when it's their only way to do merges.\n\nI do not know what \"an ideological commitment\" refers to in this\ncontext, but if I recall correctly, the reason why I originally\nadded the \"cherry picked from\" message in 48313592 (Redo \"revert\"\nusing three-way merge machinery., 2005-08-27) was because of\nend-user requests, and given that the linux-kernel was pretty much\nthe only large customer back then, I suspect it came from there.\n\nThe intention was for the original commit to be also be public and\nin the same project (e.g., you cherry-pick a commit from the main\nbranch developing towards the next great version, down to a\nmaintenance branch for the previous release), which made the commit\nobject name alone an sufficient identifier (also, this way predated\nthe invention of \"git show -s --format=reference\", so it is really\na dry hexadecimal object name and nothing else).\n\nInitially, the feature to add the message was enabled by default.\nWithout passing an option, you always got the message in the\ncherry-picked result.\n\nLater, it was found that people ended up many commits with \"cherry\npicked from\" messages that refer to commit objects that are not\navailable anywhere, because they cherry-pick across their private\nbranches while developing their patches, and the practice started\nlittering the public commits with these \"useless\" (because they do\nnot point at any commits that are part of anybody's official\nhistory) references to the original commits they were cherry-picked\nfrom. And this made us turn the feature off by default, adding the\nmessage only when the user explicitly asks to do so.\n\n"},{"id":"527676","messageId":"aN0TVmEMXOyDZEwR@ugly.lan","threadId":"64225","inReplyTo":"xmqq5xd054r2.fsf@gitster.g","subject":"Re: customizing \"cherry picked from commit abcd\" comment","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2025-10-01T11:41:10Z","receivedAt":"2025-10-01T11:41:15Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Tue, Sep 30, 2025 at 08:39:29AM -0700, Junio C Hamano wrote:\n>Oswald Buddenhagen writes:\n>> the pseudo-trailer is really just a hack in the first place, and\n>> afaict that status quo results from an ideological commitment against\n>> cherry-picks during the early history of git.\n>\n>I do not know what \"an ideological commitment\" refers to in this\n>context,\n>\nit refers to the general notion \"don't cherry-pick, but merge\", which \nrelegates cherry-picks to being a 2nd-class workflow.\n\n>The intention was for the original commit to be also be public and\n>in the same project (e.g., you cherry-pick a commit from the main\n>branch developing towards the next great version, down to a\n>maintenance branch for the previous release), [...]\n>\nyes, exactly. this trunk-first development model is quite common, and \nhas been strongly pushed by some big players in recent years. this makes \nit really surprising that git still does not provide well-integrated \nsupport for it out-of-the-box.\n\nbased on your response i conclude that you would actually welcome such a \nthing very much, but the impression of a bias against cherry-picks is \nprobably not unique to myself, and if so, it likely contributed to the \npersistence of the status quo.\n"},{"id":"527748","messageId":"xmqqa52ayq4q.fsf@gitster.g","threadId":"64225","inReplyTo":"aN0TVmEMXOyDZEwR@ugly.lan","subject":"Re: customizing \"cherry picked from commit abcd\" comment","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-02T02:49:25Z","receivedAt":"2025-10-02T02:49:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Oswald Buddenhagen writes:\n\n>>I do not know what \"an ideological commitment\" refers to in this\n>>context,\n>>\n> it refers to the general notion \"don't cherry-pick, but merge\", which\n> relegates cherry-picks to being a 2nd-class workflow.\n\nAh, that is not ideological at all, but aversion against\ncherry-picking is purely technical. With only \"cherry picked from\"\ntrailer, there is no structural link between the commit that\nintroduced the original change and the resulting commit. It would\nmake it impossible to automatically and reliably take previous\ncherry picks into account when merging back a side branch or older\nmaintenance track that are riddled with cherry picks. Compared to\nthat, a more disciplined approach to (1) fork a topic from the\noldest potential target of eventual cherry pick and develop your\nsolution there, (2) merge the result to the mainline first, per\ntrunk-first philosophy, (3) then merge the same down to the older\ntargets, is always preferrable. That way, the fact that your\nsolution is applicable even down to the \"oldest potential target\" is\nstructually encoded in the history even at step (1) by the choice of\nthe fork point, and with (2) and (3), it is obvious from the history\nstructure that the mainline and the older target both have the same\nsolution applied.\n\n>>The intention was for the original commit to be also be public and\n>>in the same project (e.g., you cherry-pick a commit from the main\n>>branch developing towards the next great version, down to a\n>>maintenance branch for the previous release), [...]\n>>\n> yes, exactly. this trunk-first development model is quite common, and\n> has been strongly pushed by some big players in recent years. this\n> makes it really surprising that git still does not provide\n> well-integrated support for it out-of-the-box.\n\nSo, I am not sure exactly what you refer to \"well-integrated\nsupport\" in this context. Not cherry-picking and instead building\non the oldest potential target for your solution does take some\ndiscipline, and there may not be a strong tool support to help\npeople pick the right fork point and merge up/down the fixes.\n\nMaking that easier would be a great addition and that would be very\nmuch welcome, I would think. \n\nBut I do not think I would approciate the vague \"well, this is not\nparent-child ancestry relation at all, but this commit and the other\ncommit that is totally unrelated in the history space are somehow\nrelated, so let's add a random commit header to record such a vague\nill defined notion that they are somehow related, and force the tool\nto pay attention to it somehow via magic.\"\n"},{"id":"527875","messageId":"aN-2gtXhBFoW5Gw5@ugly.lan","threadId":"64225","inReplyTo":"xmqqa52ayq4q.fsf@gitster.g","subject":"Re: customizing \"cherry picked from commit abcd\" comment","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2025-10-03T11:41:54Z","receivedAt":"2025-10-03T11:42:00Z","isPatch":false,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Wed, Oct 01, 2025 at 07:49:25PM -0700, Junio C Hamano wrote:\n>Oswald Buddenhagen writes:\n>>>I do not know what \"an ideological commitment\" refers to in this\n>>>context,\n>>>\n>> it refers to the general notion \"don't cherry-pick, but merge\", which\n>> relegates cherry-picks to being a 2nd-class workflow.\n>\n>Ah, that is not ideological at all, but aversion against\n>cherry-picking is purely technical.\n>\nyes, but it presumes idealized circumstances, which aren't always \nrealistic. insisting on it regardless makes it ideological.\n\n>With only \"cherry picked from\" trailer, there is no structural link \n>between the commit that introduced the original change and the \n>resulting commit.\n>It would make it impossible to automatically and reliably take previous \n>cherry picks into account when merging back a side branch or older \n>maintenance track that are riddled with cherry picks.\n>\nthat's a circular argument, because it refers back to the current \n(rather bare-bones) implementation of cherry-picks.\n\n>Compared to\n>that, a more disciplined approach to (1) fork a topic from the\n>oldest potential target of eventual cherry pick and develop your\n>solution there, (2) merge the result to the mainline first, per\n>trunk-first philosophy, (3) then merge the same down to the older\n>targets, is always preferable. That way, the fact that your\n>solution is applicable even down to the \"oldest potential target\" is\n>structurally encoded in the history even at step (1) by the choice of\n>the fork point, and with (2) and (3), it is obvious from the history\n>structure that the mainline and the older target both have the same\n>solution applied.\n>\nwell, yes, this sounds very nice ... \"on paper\".\n\nbut in reality, most people (incl. devs) aren't particularly disciplined \nby default, and it's a bit naive/presumptuous to think that one could \neducate them by withholding features that would make the result of \nsuboptimal processes suck less (cf. the recent discussion about \nautomating sign-offs [1]).\n\nbut let's assume an ideal culture where people are actually committed to \ndoing things the right way. then we still face a host of practical \nproblems:\n\nfirstly, it's often not obvious what the oldest target branch should be. \nimproved tooling (that can be realistically implemented) would go only \npart of the way, because the reasons for fixes failing in old branches \nare often subtle and unexpected. therefore, it is much more practical to \nto actually fix the trunk first, and then opportunistically try to \nbackport branch-by-branch as far as the trade-offs are deemed \nreasonable.\n\nsecondly, in your model, the fix needs to be tested on both its primary \ntarget branch and each newer branch it gets merged to - a priori, before \nit gets merged anywhere. in a big project with CI runs taking hours (and \nbeing flaky, as they always seem to be), this is a _massive_ practical \nproblem.\n\nthirdly, it happens often enough that the merge isn't clean, or some \nlogical conflict occurs (see first point). in that case one has to \n\"hide\" the fixups in the merge commits (which makes it incredibly hard \nto follow them later on), or pile fixup commits on top (making things \nnon-atomic, which also doesn't help). in such cases it is much more \n\"honest\" to actually have entirely separate commits on the branches, \nwith only weak links between them.\n\nlastly, even if everything goes well, the resulting overall history is a \ntad hard to comprehend when many fixes and branches are involved (the \nbenchmark being \"gitk --all\"). linked cherry-picks would still have to \nbe visualized, so the problem wouldn't go away entirely, but weak links \ncould be shown in a way that does not distract from the core tree \nstructure (in a cherry-pick-only model, the only merges are those of \nfeature branches to trunk, so the release branches actually form a tree, \nnot a dag, and are therefore much easier to follow).\n\n>I am not sure exactly what you refer to \"well-integrated support\" in \n>this context.\n>\n- built-in tools actually use it to its full potential\n- 3rd-party tools make heavy use of it, thanks to it being standardized\n- manual intervention is rarely necessary, everything \"just works\"\n\n>But I do not think I would appreciate the vague \"well, this is not\n>parent-child ancestry relation at all, but this commit and the other\n>commit that is totally unrelated in the history space are somehow\n>related, so let's add a random commit header to record such a vague\n>ill defined notion that they are somehow related, and force the tool\n>to pay attention to it somehow via magic.\"\n>\nehm.\nto quote two mails back:\n\nOn Tue, Sep 30, 2025 at 08:39:29AM -0700, Junio C Hamano wrote:\n>Oswald Buddenhagen writes:\n>> your particular use case would imo be better addressed by \n>> implementing bi-directional linking between picked commits via a \n>> standardized git-notes namespace.\n>\n>A nice property of notes is that they can be added after the fact \n>and can be made bidirectional, so in a workflow that allows adopting \n>this great suggestion, it is a very sensible thing to do.\n\nthat is our baseline.\n\nin the mean time, i've been thinking a bit further:\n\nwhy would we stop at cherry-picks? we can also track rebases and amends, \nthus addressing all the good questions raised in the recent thread about \nstandardizing change-ids [2].\n\nin fact, we would _have_ to track commit rewrites, as the cherry-pick \nlinks would become stale otherwise. but this can be recorded as even \nweaker provenance info in its own right, which would then serve to track \nthe evolution of commits.\n\nof course, links to short-lived commits would become stale, so they \nwould need to be garbage-collected.\n\nlots of details to think about ...\n\n[1] https://lore.kernel.org/git/aCM5JY25NVPgyYRP@chrisdown.name/T/#u\n[2] https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf1Aa5gPr0FXzdcywqUUw@mail.gmail.com/T/#u\n"}]}