{"thread":{"id":"52286","subject":"Signal conflict on merging metadata-differing patches","startedAt":"2019-11-18T17:29:31Z","lastAt":"2019-11-19T02:04:36Z","messageCount":5,"participants":["Eugeniu Rosca","Greg KH","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"386458","messageId":"20191118172917.GA6063@vmlxhi-102.adit-jv.com","threadId":"52286","inReplyTo":null,"subject":"Signal conflict on merging metadata-differing patches","fromName":"Eugeniu Rosca","fromEmail":"erosca@de.adit-jv.com","sentAt":"2019-11-18T17:29:17Z","receivedAt":"2019-11-18T17:29:31Z","isPatch":false,"sender":{"key":"erosca@de.adit-jv.com","avatar":null},"body":"Dear Git community,\n\nDue to high inflow of patches which Linux maintainers carry on their\nshoulders and due to occasionally intricate relationships between\nconsecutive revisions of the same series, it may [1] happen that two\ndistinct revisions of the same patch (differing only/mostly in\nmetadata, e.g. Author's time-stamp and commit description) may end up\nbeing merged on the same branch, without git to complain about that.\n\nIs there any \"git merge\" flag available off-the-shelf which (if used)\nwould signal such situations?\n\n[1] https://patchwork.kernel.org/patch/11135107/#23007101\n\n-- \nBest Regards,\nEugeniu\n"},{"id":"386459","messageId":"20191118173517.GA599094@kroah.com","threadId":"52286","inReplyTo":"20191118172917.GA6063@vmlxhi-102.adit-jv.com","subject":"Re: Signal conflict on merging metadata-differing patches","fromName":"Greg KH","fromEmail":"gregkh@linuxfoundation.org","sentAt":"2019-11-18T17:35:17Z","receivedAt":"2019-11-18T17:35:25Z","isPatch":false,"sender":{"key":"gregkh@linuxfoundation.org","avatar":"https://gravatar.com/avatar/e6d9136f6e3bdcb59f0e5fd15565f382da42523d273824958b9e23e73cf38e04?d=mp&s=160"},"body":"On Mon, Nov 18, 2019 at 06:29:17PM +0100, Eugeniu Rosca wrote:\n> Dear Git community,\n> \n> Due to high inflow of patches which Linux maintainers carry on their\n> shoulders and due to occasionally intricate relationships between\n> consecutive revisions of the same series, it may [1] happen that two\n> distinct revisions of the same patch (differing only/mostly in\n> metadata, e.g. Author's time-stamp and commit description) may end up\n> being merged on the same branch, without git to complain about that.\n\nWhy would git complain about that?\n\n> Is there any \"git merge\" flag available off-the-shelf which (if used)\n> would signal such situations?\n\nI don't understand what you are looking for here.  Two different\nversions of the patch were merged to different branches and then merged\ntogether, and git did the right thing with the resolution of the code.\n\nWhat more can it do here?\n\nthanks,\n\ngreg k-h\n"},{"id":"386462","messageId":"20191118184523.GA6894@vmlxhi-102.adit-jv.com","threadId":"52286","inReplyTo":"20191118173517.GA599094@kroah.com","subject":"Re: Signal conflict on merging metadata-differing patches","fromName":"Eugeniu Rosca","fromEmail":"erosca@de.adit-jv.com","sentAt":"2019-11-18T18:45:23Z","receivedAt":"2019-11-18T18:45:40Z","isPatch":false,"sender":{"key":"erosca@de.adit-jv.com","avatar":null},"body":"On Mon, Nov 18, 2019 at 06:35:17PM +0100, Greg KH wrote:\n> On Mon, Nov 18, 2019 at 06:29:17PM +0100, Eugeniu Rosca wrote:\n> > Dear Git community,\n> > \n> > Due to high inflow of patches which Linux maintainers carry on their\n> > shoulders and due to occasionally intricate relationships between\n> > consecutive revisions of the same series, it may [1] happen that two\n> > distinct revisions of the same patch (differing only/mostly in\n> > metadata, e.g. Author's time-stamp and commit description) may end up\n> > being merged on the same branch, without git to complain about that.\n> \n> Why would git complain about that?\n\nThis would help those performing the merge identify and (if needed)\navoid having several slightly different patches on the same branch.\n\n> \n> > Is there any \"git merge\" flag available off-the-shelf which (if used)\n> > would signal such situations?\n> \n> I don't understand what you are looking for here.  Two different\n> versions of the patch were merged to different branches and then merged\n> together, and git did the right thing with the resolution of the code.\n\nI personally care about commit metadata (i.e. Author's/Committer's names\nand timestamps, as well as commit description) as much as (and sometimes\nmore than) the code contents of the patch.\n\nIf I am given multiple patches which perform the same code changes, but\nprovide different descriptions, this _already_ generates potential work\non my plate, since I have to make sense of those differences when I\nstumble upon them. Which patch do I recommend to the customer (who,\nlet's say, still lives on the older v4.14 LTS), if I am asked to?\n\nWhy should I (or anybody else) spend time doing research at all, if this\ncan be avoided by just passing an additional option to \"git merge\"?\n\nIt is the most basic requirement I can think of that the maintainers\nselect the _latest_ version of a patch series, without intertwining it\nwith a superseded version.\n\n> \n> What more can it do here?\n\nCurrently Git says nothing in below merge scenarios (all of them are\nconflict-less successful merges):\n - Merge two commits which perform identical code changes but have\n   different metadata\n - Merge commit \"A\" and commits (\"B\", \"C\", \"D\"), the latter being\n   subsets of \"A\"\n\nI don't advocate for \"git merge\" to fail in the above scenarios. No.\nI just say that Git could likely detect such scenarios and help people\nlike you not pushing v2 and v5 of the same patch into the main tree.\n\n> \n> thanks,\n> \n> greg k-h\n\n-- \nBest Regards,\nEugeniu\n"},{"id":"386465","messageId":"20191118194804.GA662468@kroah.com","threadId":"52286","inReplyTo":"20191118184523.GA6894@vmlxhi-102.adit-jv.com","subject":"Re: Signal conflict on merging metadata-differing patches","fromName":"Greg KH","fromEmail":"gregkh@linuxfoundation.org","sentAt":"2019-11-18T19:48:04Z","receivedAt":"2019-11-18T19:48:13Z","isPatch":false,"sender":{"key":"gregkh@linuxfoundation.org","avatar":"https://gravatar.com/avatar/e6d9136f6e3bdcb59f0e5fd15565f382da42523d273824958b9e23e73cf38e04?d=mp&s=160"},"body":"On Mon, Nov 18, 2019 at 07:45:23PM +0100, Eugeniu Rosca wrote:\n> On Mon, Nov 18, 2019 at 06:35:17PM +0100, Greg KH wrote:\n> > On Mon, Nov 18, 2019 at 06:29:17PM +0100, Eugeniu Rosca wrote:\n> > > Dear Git community,\n> > > \n> > > Due to high inflow of patches which Linux maintainers carry on their\n> > > shoulders and due to occasionally intricate relationships between\n> > > consecutive revisions of the same series, it may [1] happen that two\n> > > distinct revisions of the same patch (differing only/mostly in\n> > > metadata, e.g. Author's time-stamp and commit description) may end up\n> > > being merged on the same branch, without git to complain about that.\n> > \n> > Why would git complain about that?\n> \n> This would help those performing the merge identify and (if needed)\n> avoid having several slightly different patches on the same branch.\n\nThe patches were not on the same branch to start with, they ended up on\ntwo different branches that got merged together at some point in time\nlater on.\n\nThis happens all the time in kernel development :)\n\n> > > Is there any \"git merge\" flag available off-the-shelf which (if used)\n> > > would signal such situations?\n> > \n> > I don't understand what you are looking for here.  Two different\n> > versions of the patch were merged to different branches and then merged\n> > together, and git did the right thing with the resolution of the code.\n> \n> I personally care about commit metadata (i.e. Author's/Committer's names\n> and timestamps, as well as commit description) as much as (and sometimes\n> more than) the code contents of the patch.\n> \n> If I am given multiple patches which perform the same code changes, but\n> provide different descriptions, this _already_ generates potential work\n> on my plate, since I have to make sense of those differences when I\n> stumble upon them. Which patch do I recommend to the customer (who,\n> let's say, still lives on the older v4.14 LTS), if I am asked to?\n\nWelcome to my life :)\n\nAs I said above, this happens quite frequently, and honestly, I just\nlive with it.  Look at the kernel's DRM branch for the main abusers of\nthis, they cherry-pick patches from their local tree to a tree to send\nto Linus today, with the sha1 in the commit message.  That means that\nLinus ends up with a commit referencing a sha1 that will not show up in\nhis tree until sometime in the _future_.\n\nIt causes havoc with my scripts and I hate it.\n\nBut, it makes things easier for the developers and maintainers of that\nsubsystem and in the end, that's what really matters.  Stable and\nbackports should almost never cause developers any problems or extra\nwork as that is not their responsibility.\n\n> Why should I (or anybody else) spend time doing research at all, if this\n> can be avoided by just passing an additional option to \"git merge\"?\n> \n> It is the most basic requirement I can think of that the maintainers\n> select the _latest_ version of a patch series, without intertwining it\n> with a superseded version.\n\nI really don't understand what you expect to have happen here.\n\nLook at the drm tree again, what should git do sometime in the future\nwhen the same \"logical change\" gets merged into Linus's tree.  I think\nit should do what it does today, handle the merge of the code changes\njust fine and allow for perfect representation at any point in time what\nthe tree looked like if you check it out then.\n\nWhat should git do instead?\n\n> > What more can it do here?\n> \n> Currently Git says nothing in below merge scenarios (all of them are\n> conflict-less successful merges):\n>  - Merge two commits which perform identical code changes but have\n>    different metadata\n>  - Merge commit \"A\" and commits (\"B\", \"C\", \"D\"), the latter being\n>    subsets of \"A\"\n> \n> I don't advocate for \"git merge\" to fail in the above scenarios. No.\n> I just say that Git could likely detect such scenarios and help people\n> like you not pushing v2 and v5 of the same patch into the main tree.\n\nBut what should it do in either of those above situations?  Fail the\nmerge?  No, that's not ok as those different branches were just fine on\ntheir own and I will never expect them to be rebased/rewritten just for\nsomething like this.  That's crazy.\n\nthanks,\n\ngreg k-h\n"},{"id":"386498","messageId":"xmqqo8x8zknn.fsf@gitster-ct.c.googlers.com","threadId":"52286","inReplyTo":"20191118194804.GA662468@kroah.com","subject":"Re: Signal conflict on merging metadata-differing patches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-19T02:04:28Z","receivedAt":"2019-11-19T02:04:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Greg KH <gregkh@linuxfoundation.org> writes:\n\n>> I don't advocate for \"git merge\" to fail in the above scenarios. No.\n>> I just say that Git could likely detect such scenarios and help people\n>> like you not pushing v2 and v5 of the same patch into the main tree.\n>\n> But what should it do in either of those above situations?  Fail the\n> merge?  No, that's not ok as those different branches were just fine on\n> their own and I will never expect them to be rebased/rewritten just for\n> something like this.  That's crazy.\n\n;-)\n\nI agree that the requested \"feature\" would make no sense for kernel\nmaintainers at various levels, as long as they are dealing with\nmerges among published branches.  What's done at the submaintainers'\ntrees are better treated as \"already cast in stone\".\n\nIt may be a useful feature when one maintains a bag of local/private\nbranches that haven't been published, though.  I however do not know\nwhat its implementation would look like X-<.\n\n"}]}