{"thread":{"id":"15404","subject":"[RFC] cherry-pick using multiple parents to implement -x","startedAt":"2008-09-07T10:34:15Z","lastAt":"2008-09-09T08:51:22Z","messageCount":25,"participants":["Stephen R. van den Berg","Jeff King","Junio C Hamano","Thomas Rast","Paolo Bonzini","Jakub Narebski","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"89964","messageId":"20080907103415.GA3139@cuci.nl","threadId":"15404","inReplyTo":null,"subject":"[RFC] cherry-pick using multiple parents to implement -x","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-09-07T10:34:15Z","receivedAt":"2008-09-07T10:34:15Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"I've been converting some old CVS repositories to git, and as it turns\nout, these repositories consist of a number of main branches of the same\nproject that were created at several points in time (the stable release\nbranches), and the branches contain numerous backports (and a few\nforward ports) between each other.\n\nI.e. the branches split off each other at various points in time, and\nevolved independently ever since (except for the numerous backports).\n\nNow, the backports can be implemented using a mere \"git cherry-pick -x\",\nbut that creates this silly text references to the original commits.\nI'd rather use something that gitk can visualise.\n\nSo I tried to use the parents of the commit to reference the origin(s).\nI.e. the first parent links to the linear history on a given branch, but\nthe second (and possibly more) parents point to the cherry-picked\nback-ported commit from another branch. This graft-constructed\nrepository is then fed to filter-branch to make it permanent.\nTo view it try: git://pike-git.lysator.liu.se/pikex\n\nThis works quite well and shows the following results:\n- gitk shows proper grafts.\n- gitk properly shows a zero-diff between the new commit and the\n commits we cherry-picked from.\n- It even works perfectly when picking from multiple parents.\n- gitk is confused in its display of tags preceding and following this\n commit (depending on the situation it mixes up the branches).\n\nObviously the reason it works rather well is because git can actually\ndistinguish between a merge and a backport because of the way the\ncontents of the trees change.\n\nThe questions now are:\n- Would there be good reason not to record the backport/forwardport\n relationship in the additional parents of a commit?\n- Since most of the git machinery (git diff, and gitk, most notably)\n seem to work just fine when using parents for that purpose, would it\n be acceptable to create a patch to cherry-pick to support an option to\n record the backport/forwardport relationship in the second (or more)\n parent field(s)?\n- And depending on an affirmative on the previous question, would it be\n acceptable to teach the gitk preceding/following tag listing to deal\n with these backport/forwardports ?\n-- \nSincerely,\n Stephen R. van den Berg.\n\n\"The future is here, it's just not widely distributed yet.\" -- William Gibson\n"},{"id":"89984","messageId":"20080907172807.GA25233@coredump.intra.peff.net","threadId":"15404","inReplyTo":"20080907103415.GA3139@cuci.nl","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-09-07T17:28:07Z","receivedAt":"2008-09-07T17:28:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 07, 2008 at 12:34:15PM +0200, Stephen R. van den Berg wrote:\n\n> The questions now are:\n> - Would there be good reason not to record the backport/forwardport\n> relationship in the additional parents of a commit?\n\nParents mean something different than just a link. If A is a parent of\nB, then that implies that at point B, we considered all of the history\nleading up to B (including A), and arrived at a certain tree state.\n\nBut cherry-picking means we looked at just A and used it to find a\ncertain tree-state. It says nothing about anything that came _before_ A.\n\nSo imagine this history:\n\nA--B--C <-- master\n \\\n D--E--F <-- side branch\n\nNow let's say we want to cherry-pick E. If we mark the cherry-picked\ncommit as a parent, we get:\n\nA--B--C--E' <-- master\n \\ /\n D----E--F <-- side branch\n\nNow let's say we want to merge the branches. What's our merge base?\nWithout your proposal, it is A, but now it is actually E. So doing a\nthree-way merge between E' and F with base E, it will look like our\nmaster branch _removed_ the change from D which is still present in F.\nAnd in a 3-way merge if one side removes something but the other side\nleaves it untouched, then the result removes it.\n\nSo the merge result is bogus, as it is missing D.\n\nI'm including a quick script below which creates this situation (it may\nneed tweaking to run on your system, but hopefully you get the point).\n\n-Peff\n\n-- >8 --\n#!/bin/sh -ex\n\nrm -rf repo\n\nchange() {\n perl -pi -e '/^'$1'$/ and $_ .= \"changed $_\"' words &&\n git commit -a -m $1 &&\n git tag $1\n}\n\nmkdir repo && cd repo && git init\ncp /usr/share/dict/words . && git add words && git commit -m initial\nchange A\nchange B\nchange C\ngit checkout -b other A\nchange D\nchange E\nchange F\ngit checkout master\ngit cherry-pick -n E\ntree=`git write-tree`\ncommit=`echo cherry pick | git commit-tree $tree -p HEAD^ -p E`\ngit update-ref HEAD $commit\n"},{"id":"89985","messageId":"7vtzcrn9uv.fsf@gitster.siamese.dyndns.org","threadId":"15404","inReplyTo":"20080907103415.GA3139@cuci.nl","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-07T17:28:56Z","receivedAt":"2008-09-07T17:28:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Stephen R. van den Berg\" writes:\n> The questions now are:\n> - Would there be good reason not to record the backport/forwardport\n> relationship in the additional parents of a commit?\n\nIn general, I do not think what you did is a good idea. The _only_ case\nyou can do what you did and keep your sanity is if you cherry-picked every\nsingle commit that matters from one branch to the other.\n\nIf something is not \"parent\", you shouldn't be recording it as such.\n\nRemember, when you are making a commit on top of one or more parents, you\nare making this statement:\n\n * I have considered all histories leading to these parent commits, and\n based on that I decided that the tree I am recording as a child of\n these parents suits the purpose of my branch better than any of them.\n\nThis applies to one-parent case as well.\n\nImagine you have two histories, forked long time ago, and have side-port\nof one commit:\n\n o---...o---B---A\n /\n ---o---o---...o---X---A'\n\nWhat side-porting A from the top history to create A' in the bottom\nhistory means is that the change between B and A in the top history, and\nno other change from the top history, is applied on top of X to produce\nstate A' in the bottom history. What B did is not included in the bottom\nhistory.\n\nIf you recorded A' with parents A and X. Here is what you would get:\n\n o---...o---B---A\n / \\ (wrong)\n ---o---o---...o---X---A'\n\nBut that is not what you did. The tree state A' lacks what B did, which\ncould be a critical security fix, and you didn't consider all history that\nleads to A when you cherry-picked it to create A'.\n\nTo put it another way, having the parent link from A' to A is a statement\nthat A' is a superset of A. Because A contains B, you are claiming A'\nalso contains B, which is not the case in your cherry-picked history.\n"},{"id":"89998","messageId":"20080907195626.GA8765@cuci.nl","threadId":"15404","inReplyTo":"20080907172807.GA25233@coredump.intra.peff.net","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-09-07T19:56:26Z","receivedAt":"2008-09-07T19:56:26Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Jeff King wrote:\n>On Sun, Sep 07, 2008 at 12:34:15PM +0200, Stephen R. van den Berg wrote:\n\n>> The questions now are:\n>> - Would there be good reason not to record the backport/forwardport\n>> relationship in the additional parents of a commit?\n\n>Parents mean something different than just a link. If A is a parent of\n>B, then that implies that at point B, we considered all of the history\n>leading up to B (including A), and arrived at a certain tree state.\n\nThat implication is not a technical one, but merely a convention in the\nmind of the git-user. Relevant, of course, but maybe we can accomodate\nboth uses.\n\n>But cherry-picking means we looked at just A and used it to find a\n>certain tree-state. It says nothing about anything that came _before_ A.\n\nCorrect.\n\n>Now let's say we want to cherry-pick E. If we mark the cherry-picked\n>commit as a parent, we get:\n\n>A--B--C--E' <-- master\n> \\ /\n> D----E--F <-- side branch\n\n>Now let's say we want to merge the branches. What's our merge base?\n>Without your proposal, it is A, but now it is actually E. So doing a\n>three-way merge between E' and F with base E, it will look like our\n>master branch _removed_ the change from D which is still present in F.\n>And in a 3-way merge if one side removes something but the other side\n>leaves it untouched, then the result removes it.\n\n>So the merge result is bogus, as it is missing D.\n\nTrue. However...\n\nWhat if the merge-base determination code is modified to behave as\nif --first-parent is specified while searching for the merge-base?\nIn that case it *will* find A as the merge-base, even in the presence of\n\"sideportlinks\".\n\nDoes that resolve all technical issues?\n-- \nSincerely,\n Stephen R. van den Berg.\n\n\"The future is here, it's just not widely distributed yet.\" -- William Gibson\n"},{"id":"89999","messageId":"20080907200441.GA26705@coredump.intra.peff.net","threadId":"15404","inReplyTo":"20080907195626.GA8765@cuci.nl","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-09-07T20:04:42Z","receivedAt":"2008-09-07T20:04:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 07, 2008 at 09:56:26PM +0200, Stephen R. van den Berg wrote:\n\n> >Parents mean something different than just a link. If A is a parent of\n> >B, then that implies that at point B, we considered all of the history\n> >leading up to B (including A), and arrived at a certain tree state.\n> \n> That implication is not a technical one, but merely a convention in the\n> mind of the git-user. Relevant, of course, but maybe we can accomodate\n> both uses.\n\nI'm not sure I agree. I believe that property is part of the definition\nof the commit DAG as originally conceived (but somebody like Linus could\nsay more). Obviously there is no formal definition, but I already\npointed out one thing that will break in that instance. I don't know if\nthere are others.\n\n> What if the merge-base determination code is modified to behave as\n> if --first-parent is specified while searching for the merge-base?\n> In that case it *will* find A as the merge-base, even in the presence of\n> \"sideportlinks\".\n\nBut then it will fail to find legitimate merge bases. So yes, you _can_\ncome up with a merge algorithm that handles this situation. But is it\nthen up to the user to say \"Oh, this parent link means something else.\nUse this other algorithm\"? In that case, it really seems we are abusing\nthe \"parent\" link and it would be more appropriate to have some _other_\ntype of link.\n\nThough I think if you look through the archives, people have argued\nagainst having any git-level link to cherry-picked commits. The history\nleading up to that cherry-pick is not necessarily of interest (though I\nthink you are proposing that it be optional to create such a link via\n-x).\n\n> Does that resolve all technical issues?\n\nI really don't know. I think you are proposing changing a core\nassumption of the data structure, so I wouldn't be too surprised if\nthere is other code that relies on it.\n\nYou can use the script I posted in my last email as a basis for a\ncherry-pick that does what you want (cherry-pick -n, write-tree,\ncommit-tree, update-ref). You might try a few experiments with that.\n\n-Peff\n"},{"id":"90001","messageId":"20080907201038.GB8765@cuci.nl","threadId":"15404","inReplyTo":"7vtzcrn9uv.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-09-07T20:10:38Z","receivedAt":"2008-09-07T20:10:38Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n>\"Stephen R. van den Berg\" writes:\n>> The questions now are:\n>> - Would there be good reason not to record the backport/forwardport\n>> relationship in the additional parents of a commit?\n\n>In general, I do not think what you did is a good idea. The _only_ case\n>you can do what you did and keep your sanity is if you cherry-picked every\n>single commit that matters from one branch to the other.\n\nWouldn't that be the normal use case for these kind of side-port\nreferences?\n\n>If something is not \"parent\", you shouldn't be recording it as such.\n\nIt depends on what you define to be a parent. The git repository\ndoesn't care either way (that's the beauty of the format definition of\nthe git repository, just as the tree snapshots allow for later more\ncomplicated diff/blame processing history, so do the parent\nrelationships allow for more complicated parent references which were\nnot imagined as the repository format was defined).\n\n>Remember, when you are making a commit on top of one or more parents, you\n>are making this statement:\n\n> * I have considered all histories leading to these parent commits, and\n> based on that I decided that the tree I am recording as a child of\n> these parents suits the purpose of my branch better than any of them.\n\nThat is a statement which depends on the view of the user. I concur\nthat up till now, that is what a user says. But maybe it is possible to\naccomodate both the traditional statement and the sideport-statement\nwithout confusing the two.\n\n>This applies to one-parent case as well.\n\n>Imagine you have two histories, forked long time ago, and have side-port\n>of one commit:\n\n>If you recorded A' with parents A and X. Here is what you would get:\n\n> o---...o---B---A\n> / \\ (wrong)\n> ---o---o---...o---X---A'\n\n>But that is not what you did. The tree state A' lacks what B did, which\n>could be a critical security fix, and you didn't consider all history that\n>leads to A when you cherry-picked it to create A'.\n\n>To put it another way, having the parent link from A' to A is a statement\n>that A' is a superset of A. Because A contains B, you are claiming A'\n>also contains B, which is not the case in your cherry-picked history.\n\nWhich existing git command actually misbehaves because it makes the\nabove assumption?\n-- \nSincerely,\n Stephen R. van den Berg.\n\n\"The future is here, it's just not widely distributed yet.\" -- William Gibson\n"},{"id":"90004","messageId":"20080907202202.GC8765@cuci.nl","threadId":"15404","inReplyTo":"20080907200441.GA26705@coredump.intra.peff.net","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-09-07T20:22:02Z","receivedAt":"2008-09-07T20:22:02Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Jeff King wrote:\n>On Sun, Sep 07, 2008 at 09:56:26PM +0200, Stephen R. van den Berg wrote:\n>> That implication is not a technical one, but merely a convention in the\n>> mind of the git-user. Relevant, of course, but maybe we can accomodate\n>> both uses.\n\n>I'm not sure I agree. I believe that property is part of the definition\n>of the commit DAG as originally conceived (but somebody like Linus could\n>say more). Obviously there is no formal definition, but I already\n>pointed out one thing that will break in that instance. I don't know if\n>there are others.\n\nYes, of course. But even then, it's merely a formal definition, the\nthing I'm after now is if there is any code that actually relies on that\nformal definition. That would be the code to review and perhaps adapt\nin order to make it support the sideport-parents without hurting the old\ndefinition.\n\n>> What if the merge-base determination code is modified to behave as\n>> if --first-parent is specified while searching for the merge-base?\n>> In that case it *will* find A as the merge-base, even in the presence of\n>> \"sideportlinks\".\n\n>But then it will fail to find legitimate merge bases. So yes, you _can_\n\nWill it? Can you give me one example where it would find the wrong one?\n\n>come up with a merge algorithm that handles this situation. But is it\n>then up to the user to say \"Oh, this parent link means something else.\n>Use this other algorithm\"?\n\nThat, of course, is unacceptable. It either is seemless and supports\nboth uses transparently, or it has to be done (if at all) using a separate\nlink (not one of the normal parents) indeed.\n\n> In that case, it really seems we are abusing\n>the \"parent\" link and it would be more appropriate to have some _other_\n>type of link.\n\nQuite.\n\n>Though I think if you look through the archives, people have argued\n>against having any git-level link to cherry-picked commits. The history\n>leading up to that cherry-pick is not necessarily of interest (though I\n>think you are proposing that it be optional to create such a link via\n>-x).\n\nOptional, indeed, and sometimes quite useful.\n\n>> Does that resolve all technical issues?\n\n>I really don't know. I think you are proposing changing a core\n>assumption of the data structure, so I wouldn't be too surprised if\n>there is other code that relies on it.\n\n>You can use the script I posted in my last email as a basis for a\n>cherry-pick that does what you want (cherry-pick -n, write-tree,\n>commit-tree, update-ref). You might try a few experiments with that.\n\nI will, thanks.\n-- \nSincerely,\n Stephen R. van den Berg.\n\n\"The future is here, it's just not widely distributed yet.\" -- William Gibson\n"},{"id":"90008","messageId":"200809072316.58516.trast@student.ethz.ch","threadId":"15404","inReplyTo":"20080907201038.GB8765@cuci.nl","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2008-09-07T21:16:54Z","receivedAt":"2008-09-07T21:16:54Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Stephen R. van den Berg wrote:\n> Junio C Hamano wrote:\n> > o---...o---B---A\n> > / \\ (wrong)\n> > ---o---o---...o---X---A'\n[...]\n> >To put it another way, having the parent link from A' to A is a statement\n> >that A' is a superset of A. Because A contains B, you are claiming A'\n> >also contains B, which is not the case in your cherry-picked history.\n> \n> Which existing git command actually misbehaves because it makes the\n> above assumption?\n\nMost importantly: merge.\n\nIf you later merge the top branch into the bottom one, the merge-base\nis now A. So any such merge, that under normal circumstances would\nhave integrated B (which as Junio said could be a very important fix!)\nwould not do so in your version.\n\nBut other things fail too: take the '..' and '...' way of specifying\nrevisions (because they consider B as \"on the bottom branch\" with that\nextra parent relationship).\n\n- Thomas\n\n-- \nThomas Rast\ntrast@student.ethz.ch\n\n\n"},{"id":"90011","messageId":"7v8wu3lipw.fsf@gitster.siamese.dyndns.org","threadId":"15404","inReplyTo":"20080907201038.GB8765@cuci.nl","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-07T22:00:27Z","receivedAt":"2008-09-07T22:00:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Stephen R. van den Berg\" writes:\n\n> Junio C Hamano wrote:\n>>\"Stephen R. van den Berg\" writes:\n>>> The questions now are:\n>>> - Would there be good reason not to record the backport/forwardport\n>>> relationship in the additional parents of a commit?\n>\n>>In general, I do not think what you did is a good idea. The _only_ case\n>>you can do what you did and keep your sanity is if you cherry-picked every\n>>single commit that matters from one branch to the other.\n>\n> Wouldn't that be the normal use case for these kind of side-port\n> references?\n> ...\n>>Remember, when you are making a commit on top of one or more parents, you\n>>are making this statement:\n>\n>> * I have considered all histories leading to these parent commits, and\n>> based on that I decided that the tree I am recording as a child of\n>> these parents suits the purpose of my branch better than any of them.\n>\n> That is a statement which depends on the view of the user. I concur\n> that up till now, that is what a user says. But maybe it is possible to\n> accomodate both the traditional statement and the sideport-statement\n> without confusing the two.\n\nRead what you are quoting again and notice I explicitly said \"suits the\npurpose of *MY* branch better\". In your side-port example, if (perhaps a\ncritical security bugfix) B does *not* matter for the purpose of *your*\nbranch (perhaps because you know the product built from the branch you are\ncherry-picking into will not be used in a context that would be affected\nby the bug), it is perfectly fine to record the cherry pick source as a\nparent of A'.\n\nOne ramification of this, however, is that you will give wrong impression\nthat such a branch contains the bugfix B to other people. By merging A'\n(not A) to their history, they think they obtained the bugfix B through\nyou, but in fact they are *not* getting the fix. Running diff between A\nto A' will reveal that in fact with the \"merge\" A' you discarded the fix\nin B. This makes your branch that has A' in its history useless for\npeople other than you. But it can still be said that the resulting\nhistory suits the purpose of *your* branch.\n\nI said (and I maintain) it is not a good idea *in general*; building that\nkind of history is just not a normal thing to do, and it will lead to\nconfusion unless you are careful and know what you are doing. I still do\nnot necessarily agree that what you did is \"the normal use case for these\nkind of side-port\", but people who consider it the normal use case would\nbe careful and know exactly what they are doing. It is Ok in that kind of\ncontext.\n\nBut just do not recommend it blindly to people who do not understand the\nconsequences, one example of which is that you cannot get the bugfix B by\nmerging A' to your branch as I mentioned above.\n\nAt that point, the choice becomes between merging from you (i.e. A') or\nnot merging from you. The other people may find that merging from you\nto honor *your* choice of discarding the bugfix made by B does *not* suit\nthe purpose of *their* branch, in which case they just do not merge from\nyou, and that is perfectly fine.\n\nIt is all relative --- each owner of history can have different objective\nof his own history, and sometimes it contradicts with each other. I do\nnot recommend recording A as a parent of A' because it explicitly makes\nthe objective *your* branch a more specialized one, \"this branch does not\ncare about the bugfix B (among other things you discarded from the\noriginal history that leads to A)\", which in general makes it less\nagreeable by other people which in turn means it is less useful to them.\n"},{"id":"90015","messageId":"7v1vzvlhpr.fsf@gitster.siamese.dyndns.org","threadId":"15404","inReplyTo":"200809072316.58516.trast@student.ethz.ch","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-07T22:22:08Z","receivedAt":"2008-09-07T22:22:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> Stephen R. van den Berg wrote:\n>> Junio C Hamano wrote:\n>> > o---...o---B---A\n>> > / \\ (wrong)\n>> > ---o---o---...o---X---A'\n> [...]\n>> >To put it another way, having the parent link from A' to A is a statement\n>> >that A' is a superset of A. Because A contains B, you are claiming A'\n>> >also contains B, which is not the case in your cherry-picked history.\n>> \n>> Which existing git command actually misbehaves because it makes the\n>> above assumption?\n>\n> Most importantly: merge.\n\nYes, and this is not about \"misbhave\" and \"assumption\". It is much more\nfundamental.\n\nStephen earlier seems to have mistaken what I taught in an earlier message:\n\n Remember, when you are making a commit on top of one or more parents, you\n are making this statement:\n\n * I have considered all histories leading to these parent commits, and\n based on that I decided that the tree I am recording as a child of\n these parents suits the purpose of my branch better than any of them.\n\n This applies to one-parent case as well.\n\nas a mere convention or something, but it is not. It is what the merge\nsemantics and merge-base computation (implemented in mathematical terms\nover commit DAG) do, expressed in layman's terms.\n\nThe decision to merge your history with A' means that (1) you trust what\nyou have done so far, (2) you trust the judgement of what the other person\nwho built the history that leads to A' as well, and (3) you deem that the\npurpose of these two histories are compatible with each other. The last\nitem is why you are merging with him.\n\n v you were here\n o---o---o---M\n / /\n o---...O---B---A /\n / \\ /\n ---o---o---...o---X---A'\n\nBecause of the \"I have considered all things behind this commit, and I\ndeclare this tree suits my purpose better than any of them\" statement when\na merge A' was made, and the fact that you trust the judgement of the\nperson who made that statement, and the fact that you think the purpose of\nhis history is compatible with yours, we look at O as the merge base when\nmerging with A' to create M, and resulting history that lead to M claims\nthat it has A _and B_, in addition to X and other developments done on the\nbottom branch of his, on top of what you used to have.\n\nHowever, the transition from A to A' involves reverting B among other\nthings, and the history M includes that revert. That's the consequence of\nyou trusting judgement made when A' was made (i.e. \"fix in B does not\nmatter, and reverting it is better for my history\") and thinking that\njudgement is compatible with the purpose of your history (i.e. \"yes, I\nagree that dropping the fix made in B does not matter to my history\neither, and that is why I am merging with A'\").\n"},{"id":"90028","messageId":"7vhc8rjyxj.fsf@gitster.siamese.dyndns.org","threadId":"15404","inReplyTo":"20080907103415.GA3139@cuci.nl","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-07T23:53:12Z","receivedAt":"2008-09-07T23:53:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Stephen R. van den Berg\" writes:\n\n> - And depending on an affirmative on the previous question, would it be\n> acceptable to teach the gitk preceding/following tag listing to deal\n> with these backport/forwardports ?\n\nEven though the answer to \"the previous question\" is a solid no, it is not\njust acceptable but it would be very useful to teach gitk that the commit\nyou cherry-picked from is somehow related to the resulting commit from the\ncherry-picking, and teach it to give you an easy access (and even a visual\ncue about their relationship) to the other commit when it is showing the\ncherry-picked commit.\n\nI think the commit object name -x records in the commit message of the\ncherry-picked one is noticed by gitweb to give you an easy access. You\ncould teach gitk a similar trick, and that would not just help cherry\npicking but also reverts, and a fix-up commit that says \"This fixes the\nregression introduced by commit 90ff09a5\".\n\nYou could further draw _different_ kind of line on the upper \"graph\" pane,\nto show that a commit is _related_ to another commit. Because cherry-pick\nrelation is about the resulting commit and the _single_ commit that was\ncherry-picked (in other words, the parent of the cherry-picked original\ndoes not have _any_ relation to the commit that results from the\ncherry-pick), such a line should be visually very distinct from the usual\nparent-child relationship, which is the gitk graph (or any other commit\nancestry graph) is about. But if it can be represented clearly, I'd\nimagine that it would be interesting to see.\n"},{"id":"90035","messageId":"20080908014959.GA29129@coredump.intra.peff.net","threadId":"15404","inReplyTo":"20080907202202.GC8765@cuci.nl","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-09-08T01:49:59Z","receivedAt":"2008-09-08T01:49:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 07, 2008 at 10:22:02PM +0200, Stephen R. van den Berg wrote:\n\n> >But then it will fail to find legitimate merge bases. So yes, you _can_\n> \n> Will it? Can you give me one example where it would find the wrong one?\n\nHow about the example I gave already? The first merge-base is E, but\nthat is not correct for the merge I gave. So you propose an algorithm\nwhich will find A. But now imagine the exact some topology, but there\nwas no cherry-pick; instead, E' is actually a merge. Wouldn't E be the\nright merge-base then?\n\nAnd yes, of course the _content_ of the trees in E' will be different in\nthose two cases. But the shape of the history graph will be the same,\nand that is the only thing that goes into finding a merge base.\n\n-Peff\n"},{"id":"90051","messageId":"20080908065723.GA29969@cuci.nl","threadId":"15404","inReplyTo":"20080908014959.GA29129@coredump.intra.peff.net","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-09-08T06:57:23Z","receivedAt":"2008-09-08T06:57:23Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Jeff King wrote:\n>On Sun, Sep 07, 2008 at 10:22:02PM +0200, Stephen R. van den Berg wrote:\n>> >But then it will fail to find legitimate merge bases. So yes, you _can_\n\n>> Will it? Can you give me one example where it would find the wrong one?\n\n>How about the example I gave already? The first merge-base is E, but\n>that is not correct for the merge I gave. So you propose an algorithm\n>which will find A. But now imagine the exact some topology, but there\n>was no cherry-pick; instead, E' is actually a merge. Wouldn't E be the\n>right merge-base then?\n\nIndeed. Q.E.D.\nI'll drop the idea with the parentlinks.\n-- \nSincerely,\n Stephen R. van den Berg.\nThe Horkheimer Effect: \"The odds of it being cloudy are directly proportional\nto the importance of an astronomical event.\"\n"},{"id":"90056","messageId":"48C4D631.3010604@gnu.org","threadId":"15404","inReplyTo":"7vtzcrn9uv.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-09-08T07:37:21Z","receivedAt":"2008-09-08T07:37:21Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Junio C Hamano wrote:\n> \"Stephen R. van den Berg\" writes:\n>> The questions now are:\n>> - Would there be good reason not to record the backport/forwardport\n>> relationship in the additional parents of a commit?\n> \n> In general, I do not think what you did is a good idea.\n\nI agree with this, though I can see the motivation (for example that\ngit-patch-id, and hence git-cherry, often do not work because of context\nchanges).\n\nThis thread, however, spurred one observation and a question.\n\nObservation: it seems to me that cherry-picking and merging are mutually\nexclusive workflows. You cherry-pick from a development branch to a\nstable branch, you merge or rebase in the other direction. Is this true\nin general? (I can see the obvious exception: you might cherry-pick\nthat very important bugfix, if you're not ready to do a full merge; but\nif you rebase, that commit will go away as soon as you do it).\n\nQuestion: how are topic branches managed in git.git? In particular, how\nare \"graduations to master\" done? Do you cherry-pick the merge commit\nthat went into \"next\"?\n\nPaolo\n"},{"id":"90057","messageId":"7v1vzvgjg1.fsf@gitster.siamese.dyndns.org","threadId":"15404","inReplyTo":"48C4D631.3010604@gnu.org","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-08T07:55:58Z","receivedAt":"2008-09-08T07:55:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paolo Bonzini writes:\n\n> Question: how are topic branches managed in git.git? In particular, how\n> are \"graduations to master\" done? Do you cherry-pick the merge commit\n> that went into \"next\"?\n\nTopics meant for master are always forked at the tip of master (or older)\nand they are merged back to master when they prove Ok.\n\nTopics that are fixes are forked at maint (or older) and if they are\ntrivial they are merged straight to maint and gets merged up to master.\nOtherwise they are merged to next, cooked for a while, then merged to\nmaster, cooked even more, and then finally merged to maint.\n\nOf course, I am not perfect (I said I am not Linus, didn't I?) and do not\nhave perfect foresight, so sometimes I do a fix directly on 'master' and\nrealize it should also apply to 'maint' some time later. They need to be\ncherry-picked.\n"},{"id":"90071","messageId":"20080908115129.GA19031@cuci.nl","threadId":"15404","inReplyTo":"7vhc8rjyxj.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-09-08T11:51:29Z","receivedAt":"2008-09-08T11:51:29Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n>\"Stephen R. van den Berg\" writes:\n>I think the commit object name -x records in the commit message of the\n>cherry-picked one is noticed by gitweb to give you an easy access. You\n>could teach gitk a similar trick, and that would not just help cherry\n>picking but also reverts, and a fix-up commit that says \"This fixes the\n>regression introduced by commit 90ff09a5\".\n\nChecking the on-disk format I see that it has been defined in a rather\nextensible way.\n\nIf we were to put the SHA1-ref somewhere in the commit message, \nfinding references to a certain commit through cherry-picks becomes\nrather disk/CPU-intensive.\n\nWould there be any objections against extending the on-disk format to\naccomodate something like the following:\n\ncommit 7df437e56b5a2c5ec7140dd097b517563db4972c\ntree a006f20b481d811ccb4846534ef6394be5bc78a8\nparent ff1e8bfcd69e5e0ee1a3167e80ef75b611f72123\nparent bbb896d8e10f736bfda8f587c0009c358c9a8599\ncousin 6ffaecc7d8b2c3c188a2efa5977a6e6605d878d9\ncousin a1184d85e8752658f02746982822f43f32316803\nauthor Junio C Hamano 1220153499 -0700\ncommitter Junio C Hamano 1220153499 -0700\n\nWhereas cherry-pick would (optionally) generate a cousin reference for every\ncommit it picks.\n\nI'm willing to do the work to fix up git-core to support the new field.\n-- \nSincerely,\n Stephen R. van den Berg.\nThe Horkheimer Effect: \"The odds of it being cloudy are directly proportional\nto the importance of an astronomical event.\"\n"},{"id":"90077","messageId":"48C522F6.7090308@gnu.org","threadId":"15404","inReplyTo":"20080908115129.GA19031@cuci.nl","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-09-08T13:04:54Z","receivedAt":"2008-09-08T13:04:54Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> commit 7df437e56b5a2c5ec7140dd097b517563db4972c\n> tree a006f20b481d811ccb4846534ef6394be5bc78a8\n> parent ff1e8bfcd69e5e0ee1a3167e80ef75b611f72123\n> parent bbb896d8e10f736bfda8f587c0009c358c9a8599\n> cousin 6ffaecc7d8b2c3c188a2efa5977a6e6605d878d9\n> cousin a1184d85e8752658f02746982822f43f32316803\n> author Junio C Hamano 1220153499 -0700\n> committer Junio C Hamano 1220153499 -0700\n\nWhat about \"origin\", and making it propagated through cherry-picks? In\nother words, if I \"cherry-pick -x\" A generating B, and do the same on B\ngenerating C, C should have A as origin. Also, \"git cherry-pick -n -x\"\nshould add the commit to a list of origins somewhere so that \"git\ncommit\" can reuse it.\n\nFurthermore, \"git cherry\" should use origins if available.\n\nPaolo\n"},{"id":"90079","messageId":"20080908134222.GA20998@cuci.nl","threadId":"15404","inReplyTo":"48C522F6.7090308@gnu.org","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-09-08T13:42:22Z","receivedAt":"2008-09-08T13:42:22Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Paolo Bonzini wrote:\n>> commit 7df437e56b5a2c5ec7140dd097b517563db4972c\n>> tree a006f20b481d811ccb4846534ef6394be5bc78a8\n>> parent ff1e8bfcd69e5e0ee1a3167e80ef75b611f72123\n>> parent bbb896d8e10f736bfda8f587c0009c358c9a8599\n>> cousin 6ffaecc7d8b2c3c188a2efa5977a6e6605d878d9\n>> cousin a1184d85e8752658f02746982822f43f32316803\n>> author Junio C Hamano 1220153499 -0700\n>> committer Junio C Hamano 1220153499 -0700\n\n>What about \"origin\", and making it propagated through cherry-picks? In\n\n\"origin\" gives a better sense of direction, so maybe that's better, yes.\n\n>other words, if I \"cherry-pick -x\" A generating B, and do the same on B\n>generating C, C should have A as origin. Also, \"git cherry-pick -n -x\"\n>should add the commit to a list of origins somewhere so that \"git\n>commit\" can reuse it.\n\nThat is debatable, and should be configurable with a switch.\nIt depends on the way of operation, I guess.\nIf one picks A -> B, and then B -> C, then usually for C you want B\nto be the origin to indicate that the patch has been tested and shaved\nto fit from A -> B, and further polished to fit from B -> C.\nUsually backporting involves shaving the patch slightly to fit the older\nbranch, and in that case it is truly more honest to point back to B\ninstead of A from C. And besides, you can follow the chain to C -> B -> A\nif you like, no information is lost.\n\n>Furthermore, \"git cherry\" should use origins if available.\n\nThat is one of the places in git that needs to accomodate the new field,\nluckily the impact on the rest of git-core is rather minimal, I think.\n-- \nSincerely,\n Stephen R. van den Berg.\nThe Horkheimer Effect: \"The odds of it being cloudy are directly proportional\nto the importance of an astronomical event.\"\n"},{"id":"90083","messageId":"m34p4qpuuu.fsf@localhost.localdomain","threadId":"15404","inReplyTo":"20080908134222.GA20998@cuci.nl","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-09-08T14:37:01Z","receivedAt":"2008-09-08T14:37:01Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Stephen R. van den Berg\" writes:\n> Paolo Bonzini wrote:\n\n>>> commit 7df437e56b5a2c5ec7140dd097b517563db4972c\n>>> tree a006f20b481d811ccb4846534ef6394be5bc78a8\n>>> parent ff1e8bfcd69e5e0ee1a3167e80ef75b611f72123\n>>> parent bbb896d8e10f736bfda8f587c0009c358c9a8599\n>>> cousin 6ffaecc7d8b2c3c188a2efa5977a6e6605d878d9\n>>> cousin a1184d85e8752658f02746982822f43f32316803\n>>> author Junio C Hamano 1220153499 -0700\n>>> committer Junio C Hamano 1220153499 -0700\n> \n>> What about \"origin\", and making it propagated through cherry-picks? In\n> \n> \"origin\" gives a better sense of direction, so maybe that's better, yes.\n> \n>> other words, if I \"cherry-pick -x\" A generating B, and do the same on B\n>> generating C, C should have A as origin. Also, \"git cherry-pick -n -x\"\n>> should add the commit to a list of origins somewhere so that \"git\n>> commit\" can reuse it.\n> \n> That is debatable, and should be configurable with a switch.\n> It depends on the way of operation, I guess.\n> If one picks A -> B, and then B -> C, then usually for C you want B\n> to be the origin to indicate that the patch has been tested and shaved\n> to fit from A -> B, and further polished to fit from B -> C.\n> Usually backporting involves shaving the patch slightly to fit the older\n> branch, and in that case it is truly more honest to point back to B\n> instead of A from C. And besides, you can follow the chain to C -> B -> A\n> if you like, no information is lost.\n> \n>> Furthermore, \"git cherry\" should use origins if available.\n> \n> That is one of the places in git that needs to accomodate the new field,\n> luckily the impact on the rest of git-core is rather minimal, I think.\n\nUnfortunately I think it is more complicated than that.\n\nIf I understand correctly (please correct me if I am wrong) you meant\n'cousin' / 'origin' link to refer only to single commit, and not to\nthe whole history ending with given commit, as it is in the case of\n'parent' link. One thing to consider is the fact that git is\n_snapshot_ based, while cherry-picking is _changeset_ based. When you\ncherry pick commit B to apply on top of commit A, what you do in fact\nis to pick (A^..A) or in other syntax (A-A^) change, and apply it on\ntop of A. So cherry picked B, let's denote it by B', is in fact\nC'=(A-A^). For example having only commit A is not enough to replay\ncherry-picking.\n\nSecond, unless such header would be for informational purposes only\n(there was even proposal to add generic 'note ' informational\nonly header, but it was shot down; see the archives), you would have\nto do quite a bit of surgery to revision walking code. For example\nyou would have to think about how commits pointed by 'origin' header\nwould be protected against pruning; if you allow to prune parents of\ngrandparents of cherry-picked commits, you would break I think a lot\nof assumptions in the code, and assumption in git design that if we\nhave commit, then all that it references should be available (well,\nthere are grafts, and there is shallow clone, but those modify\nreachability...).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"90084","messageId":"20080908143807.GB10252@spearce.org","threadId":"15404","inReplyTo":"20080908115129.GA19031@cuci.nl","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-09-08T14:38:07Z","receivedAt":"2008-09-08T14:38:07Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Stephen R. van den Berg\" wrote:\n> If we were to put the SHA1-ref somewhere in the commit message, \n> finding references to a certain commit through cherry-picks becomes\n> rather disk/CPU-intensive.\n> \n> Would there be any objections against extending the on-disk format to\n> accomodate something like the following:\n> \n> commit 7df437e56b5a2c5ec7140dd097b517563db4972c\n> tree a006f20b481d811ccb4846534ef6394be5bc78a8\n> parent ff1e8bfcd69e5e0ee1a3167e80ef75b611f72123\n> parent bbb896d8e10f736bfda8f587c0009c358c9a8599\n> cousin 6ffaecc7d8b2c3c188a2efa5977a6e6605d878d9\n> cousin a1184d85e8752658f02746982822f43f32316803\n> author Junio C Hamano 1220153499 -0700\n> committer Junio C Hamano 1220153499 -0700\n> \n> Whereas cherry-pick would (optionally) generate a cousin reference for every\n> commit it picks.\n\nSorry for wandering into a thread in the middle. But we've already\nbeen down this road before, and decided the additional header wasn't\nworth it from cherry-pick. What's changed? The fact that gitk\nwants to hyperlink this? Why can't it just regex out a string of\nhex digits longer than 6 and see if there is a commit that matches?\n\n-- \nShawn.\n"},{"id":"90105","messageId":"48C53D51.50502@gnu.org","threadId":"15404","inReplyTo":"m34p4qpuuu.fsf@localhost.localdomain","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-09-08T14:57:21Z","receivedAt":"2008-09-08T14:57:21Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> Second, unless such header would be for informational purposes only\n> (there was even proposal to add generic 'note ' informational\n> only header, but it was shot down; see the archives), you would have\n> to do quite a bit of surgery to revision walking code. For example\n> you would have to think about how commits pointed by 'origin' header\n> would be protected against pruning; if you allow to prune parents of\n> grandparents of cherry-picked commits, you would break I think a lot\n> of assumptions in the code, and assumption in git design that if we\n> have commit, then all that it references should be available (well,\n> there are grafts, and there is shallow clone, but those modify\n> reachability...).\n\nI think it would be used mostly for informational purposes (for\nhyperlinks in gitk, and in git-cherry).\n\nPaolo\n"},{"id":"90088","messageId":"20080908145802.GB8528@cuci.nl","threadId":"15404","inReplyTo":"20080908143807.GB10252@spearce.org","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-09-08T14:58:02Z","receivedAt":"2008-09-08T14:58:02Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n>\"Stephen R. van den Berg\" wrote:\n>> Whereas cherry-pick would (optionally) generate a cousin reference for every\n>> commit it picks.\n\n>Sorry for wandering into a thread in the middle. But we've already\n>been down this road before, and decided the additional header wasn't\n>worth it from cherry-pick. What's changed?\n\nI'm not familiar with the old thread. Any pointers? (I tried googling,\nbut couldn't seem to find it).\n\n> The fact that gitk\n>wants to hyperlink this? Why can't it just regex out a string of\n>hex digits longer than 6 and see if there is a commit that matches?\n\nTo avoid (accidental) duplication of the old thread, I'll try and read\nthat first.\n-- \nSincerely,\n Stephen R. van den Berg.\nThe Horkheimer Effect: \"The odds of it being cloudy are directly proportional\nto the importance of an astronomical event.\"\n"},{"id":"90089","messageId":"20080908150017.GD10252@spearce.org","threadId":"15404","inReplyTo":"20080908145802.GB8528@cuci.nl","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-09-08T15:00:17Z","receivedAt":"2008-09-08T15:00:17Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Stephen R. van den Berg\" wrote:\n> Shawn O. Pearce wrote:\n> >\"Stephen R. van den Berg\" wrote:\n> >> Whereas cherry-pick would (optionally) generate a cousin reference for every\n> >> commit it picks.\n> \n> >Sorry for wandering into a thread in the middle. But we've already\n> >been down this road before, and decided the additional header wasn't\n> >worth it from cherry-pick. What's changed?\n> \n> I'm not familiar with the old thread. Any pointers? (I tried googling,\n> but couldn't seem to find it).\n\nHere's at least one instance of it:\n\nhttp://www.gelato.unsw.edu.au/archives/git/0604/19514.html\n \nThere may be more instances in the archives.\n\n-- \nShawn.\n"},{"id":"90110","messageId":"48C53F13.10608@gnu.org","threadId":"15404","inReplyTo":"20080908143807.GB10252@spearce.org","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-09-08T15:04:51Z","receivedAt":"2008-09-08T15:04:51Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> Sorry for wandering into a thread in the middle. But we've already\n> been down this road before, and decided the additional header wasn't\n> worth it from cherry-pick. What's changed? The fact that gitk\n> wants to hyperlink this? Why can't it just regex out a string of\n> hex digits longer than 6 and see if there is a commit that matches?\n\nThe main difference is that git-cherry too often does not work right now\n(I have a local patch so that it more-or-less works with my GNU\nChangeLogs, but it does not improve the situation if rerere kicks in).\n\n(Of course git cherry could also regex out a string of hex digits longer\nthan 6 and see if there is a commit that matches).\n\nPaolo\n"},{"id":"90191","messageId":"20080909085122.GC12631@cuci.nl","threadId":"15404","inReplyTo":"20080908150017.GD10252@spearce.org","subject":"Re: [RFC] cherry-pick using multiple parents to implement -x","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-09-09T08:51:22Z","receivedAt":"2008-09-09T08:51:22Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n>\"Stephen R. van den Berg\" wrote:\n>> Shawn O. Pearce wrote:\n>> >\"Stephen R. van den Berg\" wrote:\n>> >> Whereas cherry-pick would (optionally) generate a cousin reference for every\n>> >> commit it picks.\n\n>> >Sorry for wandering into a thread in the middle. But we've already\n>> >been down this road before, and decided the additional header wasn't\n>> >worth it from cherry-pick. What's changed?\n\n>> I'm not familiar with the old thread. Any pointers? (I tried googling,\n>> but couldn't seem to find it).\n\n>Here's at least one instance of it:\n\n>http://www.gelato.unsw.edu.au/archives/git/0604/19514.html\n\nFound it, thanks. Digested it, and yes, some things changed.\nI'll make a formal proposal which should take care of all the old\nobjections.\n-- \nSincerely,\n Stephen R. van den Berg.\n\n\"Be spontaneous!\"\n"}]}