{"thread":{"id":"53666","subject":"Collaborative conflict resolution feature request","startedAt":"2020-06-12T14:08:11Z","lastAt":"2020-06-21T00:21:03Z","messageCount":32,"participants":["Curtin, Eric","Johannes Sixt","Christian Couder","Philip Oakley","Junio C Hamano","Konstantin Tokarev","Sergey Organov","Chris Torek","Stefan Moch","demerphq"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"399588","messageId":"BY5PR19MB3400EB9AD87DFE612AFD5CC390810@BY5PR19MB3400.namprd19.prod.outlook.com","threadId":"53666","inReplyTo":null,"subject":"Collaborative conflict resolution feature request","fromName":"Curtin, Eric","fromEmail":"eric.curtin@dell.com","sentAt":"2020-06-12T14:08:05Z","receivedAt":"2020-06-12T14:08:11Z","isPatch":false,"sender":{"key":"eric.curtin@dell.com","avatar":null},"body":"Hi Guys,\n\nSometimes in our private git instance in the company I work for we merge branches that have been forked for months and there can be several or more people involved in the conflict resolution.\n\nAt the moment we have two options:\n\n- One person, a branch manager, solves them by ringing people, holding meetings, using best judgement, etc.\n- Somebody solves the conflicts they are involved with, marks everything as resolved and pushes (leaving <<< ==== >>>> delimiters in for unsolved conflicts) for the next person to continue. This sort of works although you falsely mark everything as resolved, leaving merge tools useless and many broken, unbuildable commits around in the branch.\n\nNote: rebase and squashing commits is banned in our org, basically anything that would rewrite history on a remote branch.\n\nIs there any existing or upcoming feature in git that could help make conflict resolution a more distributed, collaborative kind of task?\n\nI also opened this as an issue in github as I feel it could be solved by either tool potentiall:\n\nhttps://github.com/isaacs/github/issues/1816\n\nRegards,\n\nEric Curtin\n\nSoftware Engineer\nOvens Campus,\nCork,\nIreland\n\nDell EMC\n"},{"id":"399646","messageId":"cd31ad3e-ab92-7b23-e27f-034ede094888@kdbg.org","threadId":"53666","inReplyTo":"BY5PR19MB3400EB9AD87DFE612AFD5CC390810@BY5PR19MB3400.namprd19.prod.outlook.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2020-06-13T11:33:56Z","receivedAt":"2020-06-13T11:34:01Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 12.06.20 um 16:08 schrieb Curtin, Eric:\n> Sometimes in our private git instance in the company I work for we\n> merge branches that have been forked for months and there can be\n> several or more people involved in the conflict resolution.\n> \n> At the moment we have two options:\n> \n> - One person, a branch manager, solves them by ringing people,\n> holding meetings, using best judgement, etc.\n> - Somebody solves the conflicts they are involved with, marks\n> everything as resolved and pushes (leaving <<< ==== >>>> delimiters\n> in for unsolved conflicts) for the next person to continue. This sort\n> of works although you falsely mark everything as resolved, leaving\n> merge tools useless and many broken, unbuildable commits around in\n> the branch.\n\nThird option: Do not merge the whole branch in one big do-it-all-at-once\nmerge. Instead, pick strategic commits in the history of the branch such\nthat, when you merge them one after the other, each has only conflicts\nin one particular area or topic, and so can be solved in a reasonable\namount of time with reasonable resources.\n\n-- Hannes\n"},{"id":"399648","messageId":"CAP8UFD3m9ANt6UOyOoMDy2haTJjhzL5ctFiki46ktgH3RLPqjA@mail.gmail.com","threadId":"53666","inReplyTo":"BY5PR19MB3400EB9AD87DFE612AFD5CC390810@BY5PR19MB3400.namprd19.prod.outlook.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2020-06-13T12:08:31Z","receivedAt":"2020-06-13T12:08:47Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Fri, Jun 12, 2020 at 4:11 PM Curtin, Eric wrote:\n\n> Is there any existing or upcoming feature in git that could help make conflict resolution a more distributed, collaborative kind of task?\n\nYou might want to take a look at Michael Haggerty's 'git imerge':\n\nhttps://github.com/mhagger/git-imerge\n\n> I also opened this as an issue in github as I feel it could be solved by either tool potentiall:\n>\n> https://github.com/isaacs/github/issues/1816\n\nI also made the same suggestion on the issue.\n\nBest,\nChristian.\n"},{"id":"399649","messageId":"BY5PR19MB3400AE170C9F5FF501D27B18909E0@BY5PR19MB3400.namprd19.prod.outlook.com","threadId":"53666","inReplyTo":"CAP8UFD3m9ANt6UOyOoMDy2haTJjhzL5ctFiki46ktgH3RLPqjA@mail.gmail.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Curtin, Eric","fromEmail":"eric.curtin@dell.com","sentAt":"2020-06-13T12:38:05Z","receivedAt":"2020-06-13T12:38:16Z","isPatch":false,"sender":{"key":"eric.curtin@dell.com","avatar":null},"body":"Both great ideas! And have the same theory right? Merge until you come across the first conflicting commit in a branch to make the conflicts smaller right?\n\nThanks so much for your help! Any alternative ideas? I'm definitely going to try both techniques, although imerge seems like an automation of the first idea.\n\nAnybody ever think of rewriting the imerge tool in C or whatever to get in merged into mainline git? Potentially I could do it as part of my masters thesis if Michael H and the git open source community agreed?\n\nRegards,\n\nEric Curtin\n\nSoftware Engineer\nOvens Campus,\nCork,\nIreland\n\nDell EMC\n\nFrom: Christian Couder \nSent: Saturday 13 June 2020 13:08\nTo: Curtin, Eric \nCc: git@vger.kernel.org ; Geary, Niall ; rowlands, scott ; Michael Haggerty \nSubject: Re: Collaborative conflict resolution feature request \n \n\n[EXTERNAL EMAIL] \n\nHi,\n\nOn Fri, Jun 12, 2020 at 4:11 PM Curtin, Eric wrote:\n\n> Is there any existing or upcoming feature in git that could help make conflict resolution a more distributed, collaborative kind of task?\n\nYou might want to take a look at Michael Haggerty's 'git imerge':\n\nhttps://github.com/mhagger/git-imerge\n\n> I also opened this as an issue in github as I feel it could be solved by either tool potentiall:\n>\n> https://github.com/isaacs/github/issues/1816\n\nI also made the same suggestion on the issue.\n\nBest,\nChristian."},{"id":"399650","messageId":"432b9e0b-eedf-6d39-ebc0-0416f8574afc@iee.email","threadId":"53666","inReplyTo":"BY5PR19MB3400AE170C9F5FF501D27B18909E0@BY5PR19MB3400.namprd19.prod.outlook.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2020-06-13T13:14:32Z","receivedAt":"2020-06-13T13:14:36Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 13/06/2020 13:38, Curtin, Eric wrote:\n> Both great ideas! And have the same theory right? Merge until you come across the first conflicting commit in a branch to make the conflicts smaller right?\nI've also responded to the issue on GitHub:\n\n\"Do you have an implicit XY-problem where your processes are reinforcing\nhistorical bad habits \"we merge branches that have been forked for\nmonths\"? It sounds like the process is saying \"We enjoy technical debt\"\n(of delaying the merge until it's really bad...).\n\nMaybe have a parallel 'merge' branch that is used (say weekly) to do\ntrial merges and will essentially record the conflict resolutions while\nthey are fresh in folks memories. That branch is distinct from, either\nof the two main branches, but will act as a filter and a hand rail to\nhighlight future difficulties.\"\n\nImplicit in Git is the use of small patches, easy branching and frequent\nmerges, available to the individual coder. Most older \"change control\nsystems\" focus on *stopping* change. Git promotes change, because\nreproduction & testing is cheap (almost zero). Git provides\n*authentication* of code versions. The changes in the underlying\nmaterials (from hardware to software), i.e. to bits and bytes, ripped up\nthe old rule book.\n\nAlso look at 'rerere'.\n>\n> Thanks so much for your help! Any alternative ideas? I'm definitely going to try both techniques, although imerge seems like an automation of the first idea.\n>\n> Anybody ever think of rewriting the imerge tool in C or whatever to get in merged into mainline git? Potentially I could do it as part of my masters thesis if Michael H and the git open source community agreed?\n>\n> Regards,\n>\n> Eric Curtin\n>\n> Software Engineer\n> Ovens Campus,\n> Cork,\n> Ireland\n>\n> Dell EMC\n>\n> From: Christian Couder \n> Sent: Saturday 13 June 2020 13:08\n> To: Curtin, Eric \n> Cc: git@vger.kernel.org ; Geary, Niall ; rowlands, scott ; Michael Haggerty \n> Subject: Re: Collaborative conflict resolution feature request \n>  \n>\n> [EXTERNAL EMAIL] \n>\n> Hi,\n>\n> On Fri, Jun 12, 2020 at 4:11 PM Curtin, Eric wrote:\n>\n>> Is there any existing or upcoming feature in git that could help make conflict resolution a more distributed, collaborative kind of task?\n> You might want to take a look at Michael Haggerty's 'git imerge':\n>\n> https://github.com/mhagger/git-imerge\n>\n>> I also opened this as an issue in github as I feel it could be solved by either tool potentiall:\n>>\n>> https://github.com/isaacs/github/issues/1816\n> I also made the same suggestion on the issue.\n>\n> Best,\n> Christian.\n\n"},{"id":"399657","messageId":"xmqqmu56zzip.fsf@gitster.c.googlers.com","threadId":"53666","inReplyTo":"432b9e0b-eedf-6d39-ebc0-0416f8574afc@iee.email","subject":"Re: Collaborative conflict resolution feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-13T16:44:30Z","receivedAt":"2020-06-13T16:44:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> Maybe have a parallel 'merge' branch that is used (say weekly) to do\n> trial merges and will essentially record the conflict resolutions while\n> they are fresh in folks memories. That branch is distinct from, either\n> of the two main branches, but will act as a filter and a hand rail to\n> highlight future difficulties.\"\n\nAn aside that probably would not directly help Eric, but I know the\nabove workflow helps reasonably well. The 'pu' branch is rebuilt\nnot on top of 'next', but is rebuilt with all topics (including\nthose already in 'next') in flight directly on top of 'master',\nwhich serves as a way to anticipate conflicts that will require\nresolution in the future before the topics can enter 'next' branch.\nAnd these resolutions are ...\n\n> Also look at 'rerere'.\n\n... remembered in the rerere database (and even trickier ones that\nrerere cannot handle are recorded in the merge-fix commits, but that\nis a separate story). When topics are ready to be merged to 'next'\nand to 'master', the correct resolutions are likely to be known and\nthe result tested in 'pu' and 'next', respectively, for some time\nalready.\n"},{"id":"399659","messageId":"CAP8UFD0aoNQNcNJytJBazoKj0jvWwykntHHgnYoCBXr6OmGOnQ@mail.gmail.com","threadId":"53666","inReplyTo":"BY5PR19MB3400AE170C9F5FF501D27B18909E0@BY5PR19MB3400.namprd19.prod.outlook.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2020-06-13T17:10:13Z","receivedAt":"2020-06-13T17:10:34Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sat, Jun 13, 2020 at 2:38 PM Curtin, Eric wrote:\n\n> Anybody ever think of rewriting the imerge tool in C or whatever to get in merged into mainline git? Potentially I could do it as part of my masters thesis if Michael H and the git open source community agreed?\n\n(We usually reply inline instead of top-posting here.)\n\nMy opinion is that it would be nice to have something like git-imerge\nintegrated into Git.\n"},{"id":"399667","messageId":"xmqqa716zs7w.fsf@gitster.c.googlers.com","threadId":"53666","inReplyTo":"CAP8UFD0aoNQNcNJytJBazoKj0jvWwykntHHgnYoCBXr6OmGOnQ@mail.gmail.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-13T19:22:11Z","receivedAt":"2020-06-13T19:22:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> My opinion is that it would be nice to have something like git-imerge\n> integrated into Git.\n\nI am not sure what you mean by \"integrated into\", but if you are\ntalking about somehow reinventing it, I do not think it is a good\nidea at all. \"imerge\" works quite well already.\n\nOr do you mean it would gain more exposure for being bundled\ntogether? I am not sure if that is a good idea, either. \n\nSurely, it would be convenient for end users if a single download\n(or \"apt-get install\") gives everything useful, but that does not\nhave to be done at the ultimate upstream level between me and\nMichael, and doing so at that level would mean the release schedule\nneeds to be coordinated (one may need to wait unnecessarily for the\nother's pre-release freeze period, for example), among other loss of\nflexibility. Luckily, most end users would get their Git from\npackagers and they are good at doing the bundling (i.e. the\n\"git-core\" package may \"suggest\" the \"git-imerge\" package).\n\nSo...\n\n\n"},{"id":"399668","messageId":"xmqq366yzrn1.fsf@gitster.c.googlers.com","threadId":"53666","inReplyTo":"xmqqa716zs7w.fsf@gitster.c.googlers.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-13T19:34:42Z","receivedAt":"2020-06-13T19:34:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> ... Luckily, most end users would get their Git from\n> packagers and they are good at doing the bundling (i.e. the\n> \"git-core\" package may \"suggest\" the \"git-imerge\" package).\n>\n> So...\n\nSo my answer to your idea/opinion is that we shouldn't waste\nengineering effort to \"have something like imerge integrated into\ngit itself\", but we should help distro packages to do the bundling\nof \"git\" itself and all the good things around it. One way of doing\nit may be by keeping an official curated list of \"third-party things\nwe find good\" somewhere (it can be in-tree in my release tarballs,\nbut it does not have to be---some page on git-scm.com could just be\nfine; as long as the quality of the list is maintained to our\nstandards, where the packagers and end users see it does not really\nmatter).\n\nAnd such a list would also help those who prefer to build and\ninstall things by hand.\n"},{"id":"399700","messageId":"1dd94931-83ac-4036-2317-0f3aa166d61c@iee.email","threadId":"53666","inReplyTo":"xmqq366yzrn1.fsf@gitster.c.googlers.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2020-06-14T11:05:13Z","receivedAt":"2020-06-14T11:05:33Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 13/06/2020 20:34, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> ... Luckily, most end users would get their Git from\n>> packagers and they are good at doing the bundling (i.e. the\n>> \"git-core\" package may \"suggest\" the \"git-imerge\" package).\n>>\n>> So...\n> So my answer to your idea/opinion is that we shouldn't waste\n> engineering effort to \"have something like imerge integrated into\n> git itself\", but we should help distro packages to do the bundling\n> of \"git\" itself and all the good things around it. One way of doing\n> it may be by keeping an official curated list of \"third-party things\n> we find good\" somewhere (it can be in-tree in my release tarballs,\n> but it does not have to be---some page on git-scm.com could just be\n> fine; as long as the quality of the list is maintained to our\n> standards, where the packagers and end users see it does not really\n> matter).\n>\n> And such a list would also help those who prefer to build and\n> install things by hand.\n\nFor the imerge tool, it may be worth having an extra sub-heading (Merge\nTools?) within the \"HOW TO RESOLVE CONFLICTS\" section of the git-merge\nman page.\n\nThe merge.guitool configuration does list a lot of pre-configured tools\n(the list could be moved to the mergetool man page?)\n\nCurating the list of tools maybe could be done in the same way the\nconfig entries are now being done, i.e. by area, so they can be included\nin the relevant man pages, with just a single source of 'nice tools'.\n\nPhilip\n"},{"id":"399704","messageId":"30661592138737@mail.yandex.ru","threadId":"53666","inReplyTo":"xmqqa716zs7w.fsf@gitster.c.googlers.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Konstantin Tokarev","fromEmail":"annulen@yandex.ru","sentAt":"2020-06-14T13:00:33Z","receivedAt":"2020-06-14T13:05:04Z","isPatch":false,"sender":{"key":"annulen@yandex.ru","avatar":null},"body":"\n\n13.06.2020, 22:22, \"Junio C Hamano\" :\n> Christian Couder writes:\n>\n>>  My opinion is that it would be nice to have something like git-imerge\n>>  integrated into Git.\n>\n> I am not sure what you mean by \"integrated into\", but if you are\n> talking about somehow reinventing it, I do not think it is a good\n> idea at all. \"imerge\" works quite well already.\n\nNo it doesn't. It has performance issues which makes it practically useless\non the large scale repositories because of slow progress even on fastest\nmachines. See for example \n\nhttps://github.com/mhagger/git-imerge/issues/66\nhttps://github.com/mhagger/git-imerge/issues/149\n\nAlso, maybe a bit irrelevant, but it was recently removed from Gentoo\nbecause it didn;t work with Python >= 3.7\n"},{"id":"399743","messageId":"BY5PR19MB34007DEED68D13003C614F5F909C0@BY5PR19MB3400.namprd19.prod.outlook.com","threadId":"53666","inReplyTo":"30661592138737@mail.yandex.ru","subject":"Re: Collaborative conflict resolution feature request","fromName":"Curtin, Eric","fromEmail":"eric.curtin@dell.com","sentAt":"2020-06-15T09:28:23Z","receivedAt":"2020-06-15T09:28:32Z","isPatch":false,"sender":{"key":"eric.curtin@dell.com","avatar":null},"body":"> An aside that probably would not directly help Eric, but I know the\n> above workflow helps reasonably well. The 'pu' branch is rebuilt\n> not on top of 'next', but is rebuilt with all topics (including\n> those already in 'next') in flight directly on top of 'master',\n> which serves as a way to anticipate conflicts that will require\n> resolution in the future before the topics can enter 'next' branch.\n\nOut of all the currently available options this solution helps. Thanks\nJunio! I played with incremental merge techniques this weekend.\nOne problem with incrementally merging is that you start fixing\nconflicts that are later invalidated by subsequent commits. So it\nseems you end up doing more conflict resolution than necessary.\nUnless I'm misusing the technique.\n\nI think in order to create collaborative distributed conflict resolution,\nyou'd probably need a new type of commit a \"partial-merge\" commit,\nthat is like a pseudo-commit that you can push and doesn't break\nbuilds. It would be a neat feature, at least for my team!\n\nRegards,\n\nEric Curtin\n\nSoftware Engineer\n\nOvens Campus,\nCork,\nIreland\n\nDell EMC\n"},{"id":"399744","messageId":"87zh943bda.fsf@osv.gnss.ru","threadId":"53666","inReplyTo":"432b9e0b-eedf-6d39-ebc0-0416f8574afc@iee.email","subject":"Re: Collaborative conflict resolution feature request","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2020-06-15T09:51:45Z","receivedAt":"2020-06-15T09:51:51Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Philip Oakley writes:\n\n\n[...]\n\n> Also look at 'rerere'.\n\n'rerere' is a superb feature, but isn't it local? If so, how could it\nhelp for collaboration? What's the idea? Is there a way to share\n'rerere'?\n\nThanks,\n-- Sergey\n\n\n"},{"id":"399757","messageId":"39c45b18-194c-0ff1-4a6d-1db8dee788c7@iee.email","threadId":"53666","inReplyTo":"87zh943bda.fsf@osv.gnss.ru","subject":"Re: Collaborative conflict resolution feature request","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2020-06-15T11:04:45Z","receivedAt":"2020-06-15T11:04:51Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 15/06/2020 10:51, Sergey Organov wrote:\n> Philip Oakley writes:\n>\n>\n> [...]\n>\n>> Also look at 'rerere'.\n> 'rerere' is a superb feature, but isn't it local? If so, how could it\n> help for collaboration? What's the idea? Is there a way to share\n> 'rerere'?\nI saw this (rerere) is two parts. First was to ensure Eric was aware of\nit as a possible capability for use by the 'merge manager', and others,\nso that they didn't loose sight of their conflict resolutions for the\ntime when the 'big merge window' came around. E.g. So a dev could do a\nlocal fix based on their rerere database and then send a patch to the\nmerge manager indication their approach to the resolution.\n\nMeanwhile, second, at the moment the rerere database is 'local', mainly,\nas I understand it because of the number of context lines a local user\nhas chosen (hence not immediately portable).\n\nI personally believe that it should be possible to some how exchange\nresolutions without that pre-optimisation of the context line choice. I\nhad a look back at the old rerere script and that had small fingerprints\nof each resolution stored in the database (at least as I read it).\nHowever when I look at the modern rerere database it looks like it has\nfull pre & post images, rather than just the conflicts, so I'm not yet\nsure what's really happening (i.e. I haven't dived into the c code).\n\nA possibly more sensible approach (to exchanging resolutions) is simply\nto do the merge, without commit, then save that merge as if it's a\nsingle side commit (with the other merge parent listed in the commit\nmessage), and that commit can then be pushed/pulled etc and a variant of\n`rerere train` can be used to recreate the local database. In a sense\nthe fake merge (why not a proper merge) is a variant of a stash where\nyou aren't wanting to pollute the branch trees with this extra 'flotsam'.\n\nPhilip\n>\n\n"},{"id":"399759","messageId":"c4ebf430-a69d-3d46-bfb9-37c9ece9f519@iee.email","threadId":"53666","inReplyTo":"BY5PR19MB34007DEED68D13003C614F5F909C0@BY5PR19MB3400.namprd19.prod.outlook.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2020-06-15T11:31:48Z","receivedAt":"2020-06-15T11:31:53Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 15/06/2020 10:28, Curtin, Eric wrote:\n> I think in order to create collaborative distributed conflict resolution,\n> you'd probably need a new type of commit a \"partial-merge\" commit,\n> that is like a pseudo-commit that you can push and doesn't break\n> builds. It would be a neat feature, at least for my team!\nOne thing I did note, from your prompting, is that merge doesn't take\nany `-- ` options which could allow a quick way of selecting just\nthe few files that you, or the specific dev, is able to merge, so as to\ncreate a partial merge on your side branch, and leave behind the\nremaining difficult conflicts to be resolved later by the appropriate\ndev in a sequence of rolling partial merges.\n\nIt could be effectively a special strategy. IIUC the '--' separator is\nalready supported by the underlying parser code, so may not be that\nhard? (perhaps a local contribution to the codebase;-). Just a thought.\n\nPhilip\n"},{"id":"399780","messageId":"874krczdx9.fsf@osv.gnss.ru","threadId":"53666","inReplyTo":"BY5PR19MB3400EB9AD87DFE612AFD5CC390810@BY5PR19MB3400.namprd19.prod.outlook.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2020-06-15T12:55:30Z","receivedAt":"2020-06-15T12:55:41Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"\"Curtin, Eric\" writes:\n> Hi Guys,\n>\n> Sometimes in our private git instance in the company I work for we\n> merge branches that have been forked for months and there can be\n> several or more people involved in the conflict resolution.\n>\n> At the moment we have two options:\n>\n> - One person, a branch manager, solves them by ringing people, holding\n> meetings, using best judgement, etc.\n> - Somebody solves the conflicts they are involved with, marks\n> everything as resolved and pushes (leaving <<< ==== >>>> delimiters in\n> for unsolved conflicts) for the next person to continue. This sort of\n> works although you falsely mark everything as resolved, leaving merge\n> tools useless and many broken, unbuildable commits around in the\n> branch.\n>\n> Note: rebase and squashing commits is banned in our org, basically\n> anything that would rewrite history on a remote branch.\n>\n> Is there any existing or upcoming feature in git that could help make\n> conflict resolution a more distributed, collaborative kind of task?\n\nThat'd be great.\n\nWhat we sometimes do when such a case appears (rather rarely due to\nfrequent merges, I admit) is to copy /entire/ git directory holding the\nmerge in progress to the next person in charge. This is the only way\nthat I'm aware of that keeps ability to do things like:\n\n $ f=foo.cc; git diff :1:./$f :3:./$f\n\nand\n\n $ f=foo.cc; git diff :1:./$f :2:./$f\n\nthat helps a lot with complicated conflicts.\n\nSo, if such a solution ever appears, it'd apparently need a method of\nsharing or re-creating (parts of) the index? Doesn't sound as an easy\nproblem.\n\n-- Sergey\n"},{"id":"399795","messageId":"xmqq1rmgxo67.fsf@gitster.c.googlers.com","threadId":"53666","inReplyTo":"c4ebf430-a69d-3d46-bfb9-37c9ece9f519@iee.email","subject":"Re: Collaborative conflict resolution feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-15T16:57:04Z","receivedAt":"2020-06-15T16:57:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> It could be effectively a special strategy. IIUC the '--' separator is\n> already supported by the underlying parser code, so may not be that\n> hard? (perhaps a local contribution to the codebase;-). Just a thought.\n\nAssuming that there are paths A and B that would leave conflict in\nan attempted merge between commits X and Y, you somehow resolve the\nconflict in A and leave B unresolved, what would you pass to the\nother person and ask to resolve the conflicts in B? It cannot be a\nmerge commit that records X and Y as its parents and a single tree\nobject as the result, because the whole point of this is that you do\nnot even know what to record for B.\n\nI think the most important and useful part of this is to design the\ndata format used for that task of passing from you to the other\nperson. The way to specify which paths are yours etc. are much less\ninteresting and trivial part of the story, I would think.\n\n\n\n"},{"id":"399799","messageId":"CAPx1GvdT6sZRtu8q1R9=fA-mE9pi1Ag-gKEzQfwbGap+KqSoSg@mail.gmail.com","threadId":"53666","inReplyTo":"xmqq1rmgxo67.fsf@gitster.c.googlers.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2020-06-15T17:32:33Z","receivedAt":"2020-06-15T17:32:47Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Mon, Jun 15, 2020 at 10:11 AM Junio C Hamano wrote:\n> Assuming that there are paths A and B that would leave conflict in\n> an attempted merge between commits X and Y, you somehow resolve the\n> conflict in A and leave B unresolved, what would you pass to the\n> other person and ask to resolve the conflicts in B? It cannot be a\n> merge commit that records X and Y as its parents and a single tree\n> object as the result, because the whole point of this is that you do\n> not even know what to record for B.\n>\n> I think the most important and useful part of this is to design the\n> data format used for that task of passing from you to the other\n> person. The way to specify which paths are yours etc. are much less\n> interesting and trivial part of the story, I would think.\n\nI've thought about this (some) myself in the past. It seems to me that what\nis needed is the ability to pass the complete unmerged state on. That is,\nwe need something like five commits, made in a way similar to the way a\nstash is made:\n\n * all resolved (stage 0) index entries (1 tree)\n * all index stage 1, 2, and 3 entries (3 trees)\n * and the current work-tree (1 tree)\n\nThis isn't quite complete as we also need the merge information; perhaps\nthat goes into a sixth commit, or can be wedged into the commit message\ntext of one (or more?) of the five trees.\n\nThe \"resume unresolved merge\" command then must unpack all of this\ninto the appropriate places.\n\nChris\n"},{"id":"399803","messageId":"8b0e65ec-02c1-a1c7-b363-e81f37f3fe7e@iee.email","threadId":"53666","inReplyTo":"xmqq1rmgxo67.fsf@gitster.c.googlers.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2020-06-15T19:37:33Z","receivedAt":"2020-06-15T19:37:38Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Junio,\nOn 15/06/2020 17:57, Junio C Hamano wrote:\n> Philip Oakley writes:\n>\n>> It could be effectively a special strategy. IIUC the '--' separator is\n>> already supported by the underlying parser code, so may not be that\n>> hard? (perhaps a local contribution to the codebase;-). Just a thought.\n> Assuming that there are paths A and B that would leave conflict in\n> an attempted merge between commits X and Y,\nAre we confusing the file merge X.A and Y.A with X.B and Y.B?\n\nThe scenario envisaged is that dev.a has responsibility over the .A file\nmerge, while dev.b will handle the merge for .B merge (e.g. different\nparts of the driver code).\n\n> you somehow resolve the\n> conflict in A and leave B unresolved,\nSo dev.a has resolved the .A conflicts, and the .B file(s) is still in\nthe .ours state - no conflict (i.e. we have an 'ours' strategy for all\nfiles not in the A path(s)).\n\n> what would you pass to the\n> other person and ask to resolve the conflicts in B?\nYes the merge that dev.a has performed is passed onto dev.b to complete\na second merge, apparently of the same commit, which is essentially\nsimilar to cherry picking the .B files from the .theirs commit [1].\n\n> It cannot be a\n> merge commit that records X and Y as its parents and a single tree\n> object as the result, because the whole point of this is that you do\n> not even know what to record for B.\nif no merge is attempted for paths not in the A set then the other B set\nare never 'in conflict'. As I understand Eric's conundrum, it's that a\nplain merge throws too many conflicts at the one developer. This\nsuggestion would be the way to reduce the number of conflicts just to\nthe paths the one dev can handle. A lot will depend on how Eric's\nproblem is partitioned and the depth of the overlaps.\n>\n> I think the most important and useful part of this is to design the\n> data format used for that task of passing from you to the other\n> person. The way to specify which paths are yours etc. are much less\n> interesting and trivial part of the story, I would think.\nA list of un-merged paths (i.e. not attempted) is one such format, surely?\n\nPhilip\n\n[1] actually, it's more like a soft checkout or restore of those files\nfrom the merging branch. (exchange format becomes list of merged\npaths...).  Which  then leads easily to the available `git checkout`\noptions (assuming the approach has validity for Eric's scenario).\n\n"},{"id":"399859","messageId":"CAP8UFD1y5uUkaHxtBfQFWoqXCKDod7Srfcnk0AHRVbrzit1DgQ@mail.gmail.com","threadId":"53666","inReplyTo":"CAP8UFD3m9ANt6UOyOoMDy2haTJjhzL5ctFiki46ktgH3RLPqjA@mail.gmail.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2020-06-16T09:08:42Z","receivedAt":"2020-06-16T09:08:58Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sat, Jun 13, 2020 at 2:08 PM Christian Couder\n wrote:\n>\n> On Fri, Jun 12, 2020 at 4:11 PM Curtin, Eric wrote:\n>\n> > Is there any existing or upcoming feature in git that could help make conflict resolution a more distributed, collaborative kind of task?\n>\n> You might want to take a look at Michael Haggerty's 'git imerge':\n>\n> https://github.com/mhagger/git-imerge\n\nNot sure if it could be useful in your case but some people also like\na tool called git-mediate\n\nSee:\n - https://github.com/Peaker/git-mediate\n - https://medium.com/@yairchu/how-git-mediate-made-me-stop-fearing-merge-conflicts-and-start-treating-them-like-an-easy-game-of-a2c71b919984\n"},{"id":"399891","messageId":"CAPx1Gvf5R6b1NoUWHkaqLMaj6dr51hERVvuVe1X9k3NEafnBhg@mail.gmail.com","threadId":"53666","inReplyTo":"CAPx1GvdT6sZRtu8q1R9=fA-mE9pi1Ag-gKEzQfwbGap+KqSoSg@mail.gmail.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2020-06-16T15:56:26Z","receivedAt":"2020-06-16T15:56:46Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Mon, Jun 15, 2020 at 10:32 AM Chris Torek wrote:\n> I've thought about this (some) myself in the past. It seems to me that what\n> is needed is the ability to pass the complete unmerged state on.\n\nA few further thoughts:\n\n * Given one or more saved merges and either a clean state or an\n ongoing merge, we need a tool to combine these. There are a lot of\n corner cases here but in general, if merge X has file F in conflict and\n merge Y has file F resolved, we can take the resolution from Y.\n\n * Partial merges (in the work-tree copy of a file) that are not yet added\n may be the trickiest. A simple heuristic would be to look for the\n conflict markers and see if one work-tree copy has a resolution\n where another work-tree copy has a conflict. Or, though this is\n harder, use the ours/theirs copies in the saved index trees to find\n actual conflicted regions and compare this to the work-tree copy\n to find resolved regions.\n\n * There is also an obvious question about what to do when combining\n two different proposed resolutions where the stage-zero and/or\n work-tree copies of the files don't match.\n\nNone of these preclude the basic ability to save and restore—and of\ncourse transport, through fetch/push—the unmerged state, which I think\nis the required enabling technology. The ideas above are more for\ncombining parallel merge efforts. If it's acceptable for dev A to merge\nhis/her part and pass the result to dev B, who merges theirs, and so\non, the above is not required.\n\nChris\n"},{"id":"399906","messageId":"fe2cd745-29a7-3341-d321-4199b184bc96@mail.de","threadId":"53666","inReplyTo":"39c45b18-194c-0ff1-4a6d-1db8dee788c7@iee.email","subject":"Re: Collaborative conflict resolution feature request","fromName":"Stefan Moch","fromEmail":"stefanmoch@mail.de","sentAt":"2020-06-16T17:17:14Z","receivedAt":"2020-06-16T17:17:29Z","isPatch":false,"sender":{"key":"stefanmoch@mail.de","avatar":null},"body":"Philip Oakley wrote:\n> On 15/06/2020 10:51, Sergey Organov wrote:\n>> Philip Oakley writes:\n>>\n>>\n>> [...]\n>>\n>>> Also look at 'rerere'.\n>> 'rerere' is a superb feature, but isn't it local? If so, how could it\n>> help for collaboration? What's the idea? Is there a way to share\n>> 'rerere'?\n> I saw this (rerere) is two parts. First was to ensure Eric was aware of\n> it as a possible capability for use by the 'merge manager', and others,\n> so that they didn't loose sight of their conflict resolutions for the\n> time when the 'big merge window' came around. E.g. So a dev could do a\n> local fix based on their rerere database and then send a patch to the\n> merge manager indication their approach to the resolution.\n>\n> Meanwhile, second, at the moment the rerere database is 'local', mainly,\n> as I understand it because of the number of context lines a local user\n> has chosen (hence not immediately portable).\n>\n> I personally believe that it should be possible to some how exchange\n> resolutions without that pre-optimisation of the context line choice. I\n> had a look back at the old rerere script and that had small fingerprints\n> of each resolution stored in the database (at least as I read it).\n> However when I look at the modern rerere database it looks like it has\n> full pre & post images, rather than just the conflicts, so I'm not yet\n> sure what's really happening (i.e. I haven't dived into the c code).\n>\n> A possibly more sensible approach (to exchanging resolutions) is simply\n> to do the merge, without commit, then save that merge as if it's a\n> single side commit (with the other merge parent listed in the commit\n> message), and that commit can then be pushed/pulled etc and a variant of\n> `rerere train` can be used to recreate the local database. In a sense\n> the fake merge (why not a proper merge) is a variant of a stash where\n> you aren't wanting to pollute the branch trees with this extra 'flotsam'.\n\nThere is a `contrib/rerere-train.sh` script in git's repository,\nthat can recreate rerere resolutions from existing merge commits.\n\nExtending the options Eric outlined, a collaborative conflict\nresolution workflow might thus be:\n\n * developers do test merges on temporary branches between their\n feature branch and the main development – or other feature\n branches if necessary (maybe create test merges on a regular\n basis to minimize the new conflicts)\n * these temporary branches get pushed, but not merged to other\n branches\n * the branch manager fetches these branches and uses\n `rerere-train.sh` to fill the local rerere database with\n conflict resolutions from the test merges\n * the temporary branches get deleted\n * the recorded resolutions get reused when needed (keep in mind\n rerere's gc config, see gc.rerereResolved and gc.rerereUnresolved)\n\nThe last discussion on rerere-train.sh on this list was here:\n\nhttps://lore.kernel.org/git/BZAQIE4YND2I.Z7BFCW7BLH3K@penguin/\n\n"},{"id":"399989","messageId":"xmqqa711v92s.fsf@gitster.c.googlers.com","threadId":"53666","inReplyTo":"8b0e65ec-02c1-a1c7-b363-e81f37f3fe7e@iee.email","subject":"Re: Collaborative conflict resolution feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-17T18:30:35Z","receivedAt":"2020-06-17T18:30:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> Hi Junio,\n> On 15/06/2020 17:57, Junio C Hamano wrote:\n>> Philip Oakley writes:\n>>\n>>> It could be effectively a special strategy. IIUC the '--' separator is\n>>> already supported by the underlying parser code, so may not be that\n>>> hard? (perhaps a local contribution to the codebase;-). Just a thought.\n>> Assuming that there are paths A and B that would leave conflict in\n>> an attempted merge between commits X and Y,\n> Are we confusing the file merge X.A and Y.A with X.B and Y.B?\n\nNo.\n\n> The scenario envisaged is that dev.a has responsibility over the .A file\n> merge, while dev.b will handle the merge for .B merge (e.g. different\n> parts of the driver code).\n\nYes. The question is, that division of labor is agreed between\nhumans dev.a and dev.b, but somehow need to be encoded in the data\npassed from dev.a to dev.b that says \"I've done with As and am\ncomfortable with the result; I didn't even look at Bs, but it's your\nturn to deal with them\".\n\nAfter seeing \"git pull\" leave conflicts, \"git checkout HEAD -- Bs\"\n(or checkout may be done out of MERGE_HEAD? I dunno) would be a way\nto get dev.a concentrate on As only, but the result cannot be tested\nsensibly anyway, and it cannot be committed as the result as taking\n\"ours\" or \"theirs\" for Bs was not dev.a's intention. How to express\nthat \"I didn't do anything to Bs\" in such a way that can be\ndistinguished from \"I did look at Bs, and I believe taking all from\nmy HEAD is the right resolution\" was what I asked.\n\n"},{"id":"399990","messageId":"BY5PR19MB34004535CCF180CE5C63B731909A0@BY5PR19MB3400.namprd19.prod.outlook.com","threadId":"53666","inReplyTo":"fe2cd745-29a7-3341-d321-4199b184bc96@mail.de","subject":"Re: Collaborative conflict resolution feature request","fromName":"Curtin, Eric","fromEmail":"eric.curtin@dell.com","sentAt":"2020-06-17T18:32:39Z","receivedAt":"2020-06-17T18:32:58Z","isPatch":false,"sender":{"key":"eric.curtin@dell.com","avatar":null},"body":"Hi Guys,\n\nYes I think you all understand the conundrum well. Conflict resolution\nby definition is a collaborative effort, but git doesn't support it as a,\ncollaborative effort, only one user can resolve it in git. It will be hard to\nchange my whole orgs thinking around avoiding conflicts or making\nthem easier conflicts to solve. There will always be some conflicts.\n\n> * developers do test merges on temporary branches between their\n> feature branch and the main development – or other feature\n> branches if necessary (maybe create test merges on a regular\n> basis to minimize the new conflicts)\n> * these temporary branches get pushed, but not merged to other\n> branches\n> * the branch manager fetches these branches and uses\n> `rerere-train.sh` to fill the local rerere database with\n> conflict resolutions from the test merges\n> * the temporary branches get deleted\n> * the recorded resolutions get reused when needed (keep in mind\n> rerere's gc config, see gc.rerereResolved and gc.rerereUnresolved)\n\nI certainly want to play around with rere and see if it helps things. I\nsuspect if I shared a technique like this with the 100 or so developers\non the project this will be deemed too complex though.\n\nA per file solution isn't great either as some files can be large.\nPer-conflict (between <<<< >>>> in a plain old text editor) is\nreasonable.\n\nWhat would be most ideal is a:\n\ngit merge\nfix some conflicts, not others\ngit push\n\nso someone else can work on it kind of solution....\n\nWe don't do plaintext email patches, we do typically merge\nthings via git cli/protocol or via GitHub Pull Request.\n\nRegards,\n\nEric Curtin\n\nSoftware Engineer\nOvens Campus,\nCork,\nIreland\n\nDell EMC"},{"id":"400007","messageId":"874kr92xyz.fsf@osv.gnss.ru","threadId":"53666","inReplyTo":"BY5PR19MB34004535CCF180CE5C63B731909A0@BY5PR19MB3400.namprd19.prod.outlook.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2020-06-17T21:17:56Z","receivedAt":"2020-06-17T21:18:04Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"\"Curtin, Eric\" writes:\n\n> Hi Guys,\n>\n> Yes I think you all understand the conundrum well. Conflict resolution\n> by definition is a collaborative effort, but git doesn't support it as a,\n> collaborative effort, only one user can resolve it in git.\n\n[As a side-note, I don't agree with \"by definition\" part of the\nstatement, nor with \"only one user\" part, so what is left?]\n\nWhat I'd like to stress though is that there is a pitfall here: is it\nfeasible to try to support concurrent conflict resolution, or is it to\nbe sequential (even if in multiple turns)? I incline to the latter.\n\nConcurrent conflict resolution would lead to conflicts in conflict\nresolutions, that already sounds too complex to be useful for my taste,\nand we already are in recursion that must be stopped somewhere, so it's\ntempting to stop it one level up.\n\nAdmittedly, one can try to avoid conflicts in resolutions by splitting\ncontent to independent parts (where Git is not easily applicable by\ndesign, being the tool that manages entire content), but such a split\ndoesn't sound realistic, as if it were possible, it'd be easier to apply\nit to avoid original conflicts in the first place. Then, a non-trivial\nconflict resolution often needs changes elsewhere anyway, making strict\ncontent split again problematic.\n\nOTOH, anything sequential is intrinsically difficult for a distributed\nsystem like Git, so it probably should better be implemented elsewhere.\nThis approach is simplified by the fact that fortunately Git doesn't\ncare how exactly you come-up with the resulting merge commit[*], so one\nis free to use whatever external tool to achieve his goals.\n\n-- Sergey\n\n[*] Well, it actually does care in some corner cases, e.g., when it\ndrops or tries to re-create merges on rebase, and that will only be\neliminated once \"evil merge\" concept is finally buried, for better.\n"},{"id":"400035","messageId":"CANgJU+WfW4mKotMwFS+2Kaq1pDysgJutJ2NhUvyvGgowk8JXsg@mail.gmail.com","threadId":"53666","inReplyTo":"BY5PR19MB34007DEED68D13003C614F5F909C0@BY5PR19MB3400.namprd19.prod.outlook.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2020-06-18T08:11:16Z","receivedAt":"2020-06-18T08:11:36Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On Mon, 15 Jun 2020 at 11:30, Curtin, Eric wrote:\n>\n> > An aside that probably would not directly help Eric, but I know the\n> > above workflow helps reasonably well. The 'pu' branch is rebuilt\n> > not on top of 'next', but is rebuilt with all topics (including\n> > those already in 'next') in flight directly on top of 'master',\n> > which serves as a way to anticipate conflicts that will require\n> > resolution in the future before the topics can enter 'next' branch.\n>\n> Out of all the currently available options this solution helps. Thanks\n> Junio! I played with incremental merge techniques this weekend.\n> One problem with incrementally merging is that you start fixing\n> conflicts that are later invalidated by subsequent commits. So it\n> seems you end up doing more conflict resolution than necessary.\n> Unless I'm misusing the technique.\n\nI find that the solution in these cases is to first use interactive\nrebase to squash and reorganize the commits in the branches so you\nhave a nice clean patch sequence. Once you have the branches cleaned\nup and squashed into a sequence of reasonable topic based chunks you\nthen merge, sometimes it even means you dont get conflicts at all, git\nmerge is pretty smart.\n\nAnd after that you change your workflows so the rule is that whomever\npushes first to the \"trunk branch\" wins, and the other guy has to do\nthe conflict resolution. People will start merging earlier and more\noften so they can keep the conflicts to a minimum. :-) In other words\nI second what Philip Oakley said about bad workflows. Merge early,\nmerge often, rollout early, rollout often, vote early, vote often. :-)\n\ncheers,\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"400045","messageId":"BY5PR19MB3400CD5482C8837E41DFEAF2909B0@BY5PR19MB3400.namprd19.prod.outlook.com","threadId":"53666","inReplyTo":"CANgJU+WfW4mKotMwFS+2Kaq1pDysgJutJ2NhUvyvGgowk8JXsg@mail.gmail.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Curtin, Eric","fromEmail":"eric.curtin@dell.com","sentAt":"2020-06-18T08:53:52Z","receivedAt":"2020-06-18T08:54:35Z","isPatch":false,"sender":{"key":"eric.curtin@dell.com","avatar":null},"body":"> And after that you change your workflows so the rule is that whomever\n> pushes first to the \"trunk branch\" wins, and the other guy has to do\n> the conflict resolution. People will start merging earlier and more\n> often so they can keep the conflicts to a minimum. :-) In other words\n> I second what Philip Oakley said about bad workflows. Merge early,\n> merge often, rollout early, rollout often, vote early, vote often. :-)\n\nI understand what you guys are saying, I agree merge early, merge often\ndoes work best and it's what I've most often used. Our branching strategy\nis split by subsystem (and sometimes specific features). So contributors are\nnot merging to the same long-term branches. So merge early, merge often,\ndoesn't help with conflicts.\n\nWhy? We don't have so much automated tests, etc. And that's not an\neasy problem to solve although we are trying to improve in this area. For us\nto make worthwhile tests, we would have to emulate a lot of hardware\nfrom external vendors. Out test hardware is often shared among many.\nSo branching ensures that if we hit problems, it most likely came from\nwithin our group, in the area of the code we are most knowledgeable\nabout.\n\nAnd when your branching strategy is like this, it ends up being the\nbranch managers merging and having to fix conflicts, not the individual\ncontributors. In our git repo you will see broken commits with these\ndelimiters in (<<<< ==== >>>>) in order to \"fake\" this kind of\ncollaborative conflict resolution feature as described in the initial email.\n\nRegards,\n\nEric Curtin\n\nSoftware Engineer\nOvens Campus,\nCork,\nIreland\n\nDell EMC\n"},{"id":"400046","messageId":"BY5PR19MB34004D9F72F6B66376F8E986909B0@BY5PR19MB3400.namprd19.prod.outlook.com","threadId":"53666","inReplyTo":"BY5PR19MB3400CD5482C8837E41DFEAF2909B0@BY5PR19MB3400.namprd19.prod.outlook.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Curtin, Eric","fromEmail":"eric.curtin@dell.com","sentAt":"2020-06-18T09:28:35Z","receivedAt":"2020-06-18T09:28:44Z","isPatch":false,"sender":{"key":"eric.curtin@dell.com","avatar":null},"body":"> What I'd like to stress though is that there is a pitfall here: is it\n> feasible to try to support concurrent conflict resolution, or is it to\n> be sequential (even if in multiple turns)? I incline to the latter.\n\n> Concurrent conflict resolution would lead to conflicts in conflict\n> resolutions, that already sounds too complex to be useful for my taste,\n> and we already are in recursion that must be stopped somewhere, so it's\n> tempting to stop it one level up.\n\nI think concurrent doesn't make sense, only sequential.\n\n> I find that the solution in these cases is to first use interactive\n> rebase to squash and reorganize the commits in the branches so you\n> have a nice clean patch sequence. Once you have the branches cleaned\n> up and squashed into a sequence of reasonable topic based chunks you\n> then merge, sometimes it even means you dont get conflicts at all, git\n> merge is pretty smart.\n\nAgain, as said in the initial email, anything that rewrites history,\nrecreates SHA's (such as rebase, squash, etc.) on a remote\nbranch is not allowed in our repo. Of course with unpushed\ncommits you can do some of these things as the remote end\nknows no different.\n\nRegards,\n\nEric Curtin\n\nSoftware Engineer\nOvens Campus,\nCork,\nIreland\n\nDell EMC\n"},{"id":"400048","messageId":"CANgJU+V7MUC85n-=_yQG05w6MOmSG_ZvmQBJVTk2qRyk=7giZQ@mail.gmail.com","threadId":"53666","inReplyTo":"BY5PR19MB34004D9F72F6B66376F8E986909B0@BY5PR19MB3400.namprd19.prod.outlook.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2020-06-18T10:14:33Z","receivedAt":"2020-06-18T10:14:52Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On Thu, 18 Jun 2020 at 11:28, Curtin, Eric wrote:\n>\n> > What I'd like to stress though is that there is a pitfall here: is it\n> > feasible to try to support concurrent conflict resolution, or is it to\n> > be sequential (even if in multiple turns)? I incline to the latter.\n>\n> > Concurrent conflict resolution would lead to conflicts in conflict\n> > resolutions, that already sounds too complex to be useful for my taste,\n> > and we already are in recursion that must be stopped somewhere, so it's\n> > tempting to stop it one level up.\n>\n> I think concurrent doesn't make sense, only sequential.\n>\n> > I find that the solution in these cases is to first use interactive\n> > rebase to squash and reorganize the commits in the branches so you\n> > have a nice clean patch sequence. Once you have the branches cleaned\n> > up and squashed into a sequence of reasonable topic based chunks you\n> > then merge, sometimes it even means you dont get conflicts at all, git\n> > merge is pretty smart.\n>\n> Again, as said in the initial email, anything that rewrites history,\n> recreates SHA's (such as rebase, squash, etc.) on a remote\n> branch is not allowed in our repo. Of course with unpushed\n> commits you can do some of these things as the remote end\n> knows no different.\n\nAh I see, I missed that detail. We have a similar rule at work but\nonly for the \"trunk\" branch (what most people call \"master\"), topic\nbranches are allowed to change before the merge to trunk.\n\nI guess there is no way to convince your policy makers that if commit\nA and B are different but have the same tree hash they refer to the\nsame state on the disk? I have had audit conversations like that.\n\nAnyway, sorry my reply wasn't helpful. Good luck.\n\ncheers,\nYves\n"},{"id":"400103","messageId":"BY5PR19MB34000FB239B2B7BD996A17C790980@BY5PR19MB3400.namprd19.prod.outlook.com","threadId":"53666","inReplyTo":"CANgJU+V7MUC85n-=_yQG05w6MOmSG_ZvmQBJVTk2qRyk=7giZQ@mail.gmail.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Curtin, Eric","fromEmail":"eric.curtin@dell.com","sentAt":"2020-06-19T09:17:38Z","receivedAt":"2020-06-19T09:17:57Z","isPatch":false,"sender":{"key":"eric.curtin@dell.com","avatar":null},"body":"> Anyway, sorry my reply wasn't helpful. Good luck.\n\nNot at all, I do appreciate all the suggestions, I learned a lot from this\nthread in general. I think everybody in this thread has been very helpful.\n\nThis thread has gone a little cold. I did have a think about the sequential\nvs concurrent resolutions and even had a conversation with one of my colleagues\nabout it.\n\nWould it be reasonable if anyone could push a partial resolution but the book\nstops there (once a user hits a conflict of a conflict is must be solved\nlocally)? I agree it doesn't make sense in most cases to support pushing\nrecursive conflict resolutions (even though the other part of me says if the\nusers wants to go down that path why stop them? You could even have a config\nsetting to allow N levels of conflicts to be pushed, the default setting being\nexactly the way things are, none or 0!).\n\nI know in my project we already \"fake\" this functionality like pointed out in\nthe first email, it's just unclean the way we do it, leaves broken commits\nin the repo, you can no longer use difftools, etc.\n\nShould I even consider this as a research idea for my thesis? Or another way\nof wording this is, if someone sent the code to the git maintainers Junio, etc.\nwould it be merged into git?\n\nRegards,\n\nEric Curtin\n\nSoftware Engineer\n\nOvens Campus,\nCork,\nIreland\n\nDell EMC\n"},{"id":"400254","messageId":"CAP8UFD2t6OVFWjm76oy=+Fgo1UUepwHTpOWM8vmCYzs9hSy_ug@mail.gmail.com","threadId":"53666","inReplyTo":"BY5PR19MB34000FB239B2B7BD996A17C790980@BY5PR19MB3400.namprd19.prod.outlook.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2020-06-20T16:09:54Z","receivedAt":"2020-06-20T16:10:10Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Jun 19, 2020 at 11:17 AM Curtin, Eric wrote:\n\n> Would it be reasonable if anyone could push a partial resolution but the book\n> stops there (once a user hits a conflict of a conflict is must be solved\n> locally)? I agree it doesn't make sense in most cases to support pushing\n> recursive conflict resolutions (even though the other part of me says if the\n> users wants to go down that path why stop them? You could even have a config\n> setting to allow N levels of conflicts to be pushed, the default setting being\n> exactly the way things are, none or 0!).\n>\n> I know in my project we already \"fake\" this functionality like pointed out in\n> the first email, it's just unclean the way we do it, leaves broken commits\n> in the repo, you can no longer use difftools, etc.\n>\n> Should I even consider this as a research idea for my thesis? Or another way\n> of wording this is, if someone sent the code to the git maintainers Junio, etc.\n> would it be merged into git?\n\nI think it could be an interesting feature to add to Git, as I agree\nthat some people often have this kind of issues with conflicts.\n\nWhat could perhaps work is to develop a new command, maybe called `git\nconflict` with subcommands for example to load, save and maybe push,\nfetch and resolve partial resolutions of conflicts. The conflicts\ncould perhaps be stored as commits in the \"refs/conflicts/\" ref\nnamespace.\n"},{"id":"400261","messageId":"BY5PR19MB3400DC6B6065C1FFF2ED289890990@BY5PR19MB3400.namprd19.prod.outlook.com","threadId":"53666","inReplyTo":"CAP8UFD2t6OVFWjm76oy=+Fgo1UUepwHTpOWM8vmCYzs9hSy_ug@mail.gmail.com","subject":"Re: Collaborative conflict resolution feature request","fromName":"Curtin, Eric","fromEmail":"eric.curtin@dell.com","sentAt":"2020-06-21T00:20:46Z","receivedAt":"2020-06-21T00:21:03Z","isPatch":false,"sender":{"key":"eric.curtin@dell.com","avatar":null},"body":"> I think it could be an interesting feature to add to Git, as I agree\n> that some people often have this kind of issues with conflicts.\n>\n> What could perhaps work is to develop a new command, maybe called `git\n> conflict` with subcommands for example to load, save and maybe push,\n> fetch and resolve partial resolutions of conflicts. The conflicts\n> could perhaps be stored as commits in the \"refs/conflicts/\" ref\n> namespace.\n\nYes and actually the more I read about things like `git rerere`, most of the\ncomponents are already there in git. What this concept kind of is, is a\npushable git rerere cache. A workflow could be something like:\n\ngit merge/rebase # fails with conflicts, maybe a prompt that to tell the user that some conflict resolutions have already been pushed\ngit rerere pop/apply # apply the already pushed conflicts\n# fix your conflict with whatever technique or tool you prefer\ngit rerere create # commit your rerere (stash uses the term create) writing a message explaining why you resolved this conflict in a certain way\ngit push # or maybe `git rerere push` so the next user can \"git fetch/git merge/etc.\" and work on the conflict resolution\n\nAnd maybe add some other git stash like commands like show/list.\nSo other users can see who solved what conflict and why that decision was\nmade. I'm using terms like pop/apply/create just to be consistent with stash\nalso. The reason I make that a manual step and not an automatic step like\ngit rerere tends to do, is that existing users of git won't be aware of these\nautomated conflict resolutions and I'm sure many people won't like these\nbeing applied automatically by default.\n\nAdmittedly I don't use git stash for temporary local changes, I just use\ncommits and branches, amend them, delete them etc. as I see fit. But I\nthink the concept is very similar, these are not complete buildable commits.\n\nBut I think you're right Chris if we start from scratch and call it `git conflict`\n(although I was thinking of maybe `git resolve` or `git re`, since rerere already\nabbreviates resolution to just re) we don't have to worry about backwards\ncompatibility with existing commands designed for a different purpose\nlike rerere. I'm not too worried about the naming as long as the workflow\nis easy to use.\n\nI might fly this by my lecturers as a research project. What do you think Chris\nand Junio? I'd be happy to send you patches of the work in progress as it's\ngoing along if you guys would be happy to see them?\n\nRegards,\n\nEric Curtin\n\nSoftware Engineer\nOvens Campus,\nCork,\nIreland\n\nDell EMC\n"}]}