{"thread":{"id":"57153","subject":"request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts","startedAt":"2021-12-27T12:52:09Z","lastAt":"2021-12-29T14:52:04Z","messageCount":6,"participants":["Andrey Butirsky","Erik Cervin Edin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"444997","messageId":"3e1548ab-5e20-9555-bd10-d6cbf2ffbce4@gmail.com","threadId":"57153","inReplyTo":null,"subject":"request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts","fromName":"Andrey Butirsky","fromEmail":"butirsky@gmail.com","sentAt":"2021-12-27T12:52:03Z","receivedAt":"2021-12-27T12:52:09Z","isPatch":false,"sender":{"key":"butirsky@gmail.com","avatar":null},"body":"Hi, stumbling upon this again and again, so decided to write finally,\n\nwhile in conflicting state, the only thing we can do to auto-pick one or \nanother side of conflict is passing --ours/--theirs option to git-checkout:\ngit checkout --ours/--theirs <path>\n\nThe problem is - it doesn't actually do a _merge_, i.e. you lose all \nnon-conflicted changes.\n\nThere is no easy way to solve that currently without third-party tools.\n\nThis link illustrates it:\nhttps://stackoverflow.com/a/68498101/1063363\n\nProposal:\nShell we add -X <strategy-option> to git checkout <path> to allow it do \na merge and _actually solve_ merge conflicts?\nThat would be in-pair with other commands taking the option already: \ngit-merge, git-rebase, (etc.?)\n\n"},{"id":"445135","messageId":"a8f3246f-2b50-e713-16c3-1d23b80a42a1@gmail.com","threadId":"57153","inReplyTo":"CA+JQ7M-By65FVPnMFnwE8zx3T4O7DV3_5Kf2P6eZhP4Zcemorg@mail.gmail.com","subject":"Re: request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts","fromName":"Andrey Butirsky","fromEmail":"butirsky@gmail.com","sentAt":"2021-12-28T20:44:35Z","receivedAt":"2021-12-28T20:44:41Z","isPatch":false,"sender":{"key":"butirsky@gmail.com","avatar":null},"body":"Thanks Erik, please post your further replies to the mailing list so \nothers could see it also.\n\nOn a topic,\nI'm not familiar with Git code-base so don't know if it even possible in \nit's current architecture..\n\n\nOn 28.12.2021 20:32, Erik Cervin Edin wrote:\n> That's my answer =)\n>\n> I think adding a merge strategy option to checkout might be useful\n>\n> On Mon, Dec 27, 2021 at 4:49 PM Andrey Butirsky <butirsky@gmail.com> wrote:\n>> Hi, stumbling upon this again and again, so decided to write finally,\n>>\n>> while in conflicting state, the only thing we can do to auto-pick one or\n>> another side of conflict is passing --ours/--theirs option to git-checkout:\n>> git checkout --ours/--theirs <path>\n>>\n>> The problem is - it doesn't actually do a _merge_, i.e. you lose all\n>> non-conflicted changes.\n>>\n>> There is no easy way to solve that currently without third-party tools.\n>>\n>> This link illustrates it:\n>> https://stackoverflow.com/a/68498101/1063363\n>>\n>> Proposal:\n>> Shell we add -X <strategy-option> to git checkout <path> to allow it do\n>> a merge and _actually solve_ merge conflicts?\n>> That would be in-pair with other commands taking the option already:\n>> git-merge, git-rebase, (etc.?)\n>>\n"},{"id":"445145","messageId":"CA+JQ7M9Ht5vSfDDEuYyK7pBPBvgjzi7L6jEYX8dkP4PMFK-M2Q@mail.gmail.com","threadId":"57153","inReplyTo":"a8f3246f-2b50-e713-16c3-1d23b80a42a1@gmail.com","subject":"Re: request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts","fromName":"Erik Cervin Edin","fromEmail":"erik@cervined.in","sentAt":"2021-12-28T21:50:31Z","receivedAt":"2021-12-28T21:51:09Z","isPatch":false,"sender":{"key":"erik@cervined.in","avatar":null},"body":"> On Tue, Dec 28, 2021 at 9:44 PM Andrey Butirsky <butirsky@gmail.com> wrote:\n> Thanks Erik, please post your further replies to the mailing list so\n> others could see it also.\n\nMea culpa\n\n> On a topic,\n> I'm not familiar with Git code-base so don't know if it even possible in\n> it's current architecture..\n\nIt looks like\nbuiltin/checkout.c checkout_merged\nis responsible and calls\nll-merge.c ll_merge\n\nI think other commands that allow merging strategies may use other\n\"merge drivers\".\n\nFrom commit a944af1d86e6171d68ed2a3aa67b1d68f00e1fe8\n> merge: teach -Xours/-Xtheirs to binary ll-merge driver\n>\n> The (discouraged) -Xours/-Xtheirs modes of merge are supposed to\n> give a quick and dirty way to come up with a random mixture of\n> cleanly merged parts and punted conflict resolution to take contents\n> from one side in conflicting parts.  These options however were only\n> passed down to the low level merge driver for text.\n\nIt looks possible.\nBut perhaps the sentiment is that it's not adviceable?\n"},{"id":"445172","messageId":"CA+JQ7M-gornjkB78Dgx-bHW7Ps=C2936vDNUakQ-VG8KAyZ=YA@mail.gmail.com","threadId":"57153","inReplyTo":"CA+JQ7M9Ht5vSfDDEuYyK7pBPBvgjzi7L6jEYX8dkP4PMFK-M2Q@mail.gmail.com","subject":"Re: request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts","fromName":"Erik Cervin Edin","fromEmail":"erik@cervined.in","sentAt":"2021-12-29T12:13:10Z","receivedAt":"2021-12-29T12:13:49Z","isPatch":false,"sender":{"key":"erik@cervined.in","avatar":null},"body":"On a tangent, you can set up your own merge tools.\n\nSo in git config you can add something like:\n\n[mergetool \"both\"]\ncmd = \"sed -i -e '/^<<<<<<<$/d' -e '/^=======$/d' -e '/^>>>>>>>$/d' -- $MERGED\"\n\nand call it with git mergetool --tool=both\n\nOn Tue, Dec 28, 2021 at 10:50 PM Erik Cervin Edin <erik@cervined.in> wrote:\n>\n> > On Tue, Dec 28, 2021 at 9:44 PM Andrey Butirsky <butirsky@gmail.com> wrote:\n> > Thanks Erik, please post your further replies to the mailing list so\n> > others could see it also.\n>\n> Mea culpa\n>\n> > On a topic,\n> > I'm not familiar with Git code-base so don't know if it even possible in\n> > it's current architecture..\n>\n> It looks like\n> builtin/checkout.c checkout_merged\n> is responsible and calls\n> ll-merge.c ll_merge\n>\n> I think other commands that allow merging strategies may use other\n> \"merge drivers\".\n>\n> From commit a944af1d86e6171d68ed2a3aa67b1d68f00e1fe8\n> > merge: teach -Xours/-Xtheirs to binary ll-merge driver\n> >\n> > The (discouraged) -Xours/-Xtheirs modes of merge are supposed to\n> > give a quick and dirty way to come up with a random mixture of\n> > cleanly merged parts and punted conflict resolution to take contents\n> > from one side in conflicting parts.  These options however were only\n> > passed down to the low level merge driver for text.\n>\n> It looks possible.\n> But perhaps the sentiment is that it's not adviceable?\n"},{"id":"445175","messageId":"fffeed2f-c956-d34f-ea5f-73f52e2d2be4@gmail.com","threadId":"57153","inReplyTo":"CA+JQ7M-gornjkB78Dgx-bHW7Ps=C2936vDNUakQ-VG8KAyZ=YA@mail.gmail.com","subject":"Re: request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts","fromName":"Andrey Butirsky","fromEmail":"butirsky@gmail.com","sentAt":"2021-12-29T13:35:07Z","receivedAt":"2021-12-29T13:35:13Z","isPatch":false,"sender":{"key":"butirsky@gmail.com","avatar":null},"body":"This is exactly what I tried to avoid, since Git already seem has all \nthe needed under the hood to prevent such disaster..\n\nOn 29.12.2021 15:13, Erik Cervin Edin wrote:\n> On a tangent, you can set up your own merge tools.\n>\n> So in git config you can add something like:\n>\n> [mergetool \"both\"]\n> cmd = \"sed -i -e '/^<<<<<<<$/d' -e '/^=======$/d' -e '/^>>>>>>>$/d' -- $MERGED\"\n>\n> and call it with git mergetool --tool=both\n"},{"id":"445179","messageId":"CA+JQ7M9ANzeiZC7uLPoe671hT8wGDyO7tWu7+YxfDB0QE6YR5Q@mail.gmail.com","threadId":"57153","inReplyTo":"fffeed2f-c956-d34f-ea5f-73f52e2d2be4@gmail.com","subject":"Re: request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts","fromName":"Erik Cervin Edin","fromEmail":"erik@cervined.in","sentAt":"2021-12-29T14:51:26Z","receivedAt":"2021-12-29T14:52:04Z","isPatch":false,"sender":{"key":"erik@cervined.in","avatar":null},"body":"On Wed, Dec 29, 2021 at 2:35 PM Andrey Butirsky <butirsky@gmail.com> wrote:\n>\n> This is exactly what I tried to avoid, since Git already seem has all\n> the needed under the hood to prevent such disaster..\n\nIt'd be neat if you could specify -X ours/theirs/both\nBut I'm not sure I would describe the current situation as disastrous\n"}]}