* request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts @ 2021-12-27 12:52 Andrey Butirsky [not found] ` <CA+JQ7M-By65FVPnMFnwE8zx3T4O7DV3_5Kf2P6eZhP4Zcemorg@mail.gmail.com> 0 siblings, 1 reply; 6+ messages in thread From: Andrey Butirsky @ 2021-12-27 12:52 UTC (permalink / raw) To: git Hi, stumbling upon this again and again, so decided to write finally, while in conflicting state, the only thing we can do to auto-pick one or another side of conflict is passing --ours/--theirs option to git-checkout: git checkout --ours/--theirs <path> The problem is - it doesn't actually do a _merge_, i.e. you lose all non-conflicted changes. There is no easy way to solve that currently without third-party tools. This link illustrates it: https://stackoverflow.com/a/68498101/1063363 Proposal: Shell we add -X <strategy-option> to git checkout <path> to allow it do a merge and _actually solve_ merge conflicts? That would be in-pair with other commands taking the option already: git-merge, git-rebase, (etc.?) ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CA+JQ7M-By65FVPnMFnwE8zx3T4O7DV3_5Kf2P6eZhP4Zcemorg@mail.gmail.com>]
* Re: request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts [not found] ` <CA+JQ7M-By65FVPnMFnwE8zx3T4O7DV3_5Kf2P6eZhP4Zcemorg@mail.gmail.com> @ 2021-12-28 20:44 ` Andrey Butirsky 2021-12-28 21:50 ` Erik Cervin Edin 0 siblings, 1 reply; 6+ messages in thread From: Andrey Butirsky @ 2021-12-28 20:44 UTC (permalink / raw) To: git; +Cc: Erik Cervin Edin Thanks Erik, please post your further replies to the mailing list so others could see it also. On a topic, I'm not familiar with Git code-base so don't know if it even possible in it's current architecture.. On 28.12.2021 20:32, Erik Cervin Edin wrote: > That's my answer =) > > I think adding a merge strategy option to checkout might be useful > > On Mon, Dec 27, 2021 at 4:49 PM Andrey Butirsky <butirsky@gmail.com> wrote: >> Hi, stumbling upon this again and again, so decided to write finally, >> >> while in conflicting state, the only thing we can do to auto-pick one or >> another side of conflict is passing --ours/--theirs option to git-checkout: >> git checkout --ours/--theirs <path> >> >> The problem is - it doesn't actually do a _merge_, i.e. you lose all >> non-conflicted changes. >> >> There is no easy way to solve that currently without third-party tools. >> >> This link illustrates it: >> https://stackoverflow.com/a/68498101/1063363 >> >> Proposal: >> Shell we add -X <strategy-option> to git checkout <path> to allow it do >> a merge and _actually solve_ merge conflicts? >> That would be in-pair with other commands taking the option already: >> git-merge, git-rebase, (etc.?) >> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts 2021-12-28 20:44 ` Andrey Butirsky @ 2021-12-28 21:50 ` Erik Cervin Edin 2021-12-29 12:13 ` Erik Cervin Edin 0 siblings, 1 reply; 6+ messages in thread From: Erik Cervin Edin @ 2021-12-28 21:50 UTC (permalink / raw) To: Andrey Butirsky; +Cc: git > On Tue, Dec 28, 2021 at 9:44 PM Andrey Butirsky <butirsky@gmail.com> wrote: > Thanks Erik, please post your further replies to the mailing list so > others could see it also. Mea culpa > On a topic, > I'm not familiar with Git code-base so don't know if it even possible in > it's current architecture.. It looks like builtin/checkout.c checkout_merged is responsible and calls ll-merge.c ll_merge I think other commands that allow merging strategies may use other "merge drivers". From commit a944af1d86e6171d68ed2a3aa67b1d68f00e1fe8 > merge: teach -Xours/-Xtheirs to binary ll-merge driver > > The (discouraged) -Xours/-Xtheirs modes of merge are supposed to > give a quick and dirty way to come up with a random mixture of > cleanly merged parts and punted conflict resolution to take contents > from one side in conflicting parts. These options however were only > passed down to the low level merge driver for text. It looks possible. But perhaps the sentiment is that it's not adviceable? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts 2021-12-28 21:50 ` Erik Cervin Edin @ 2021-12-29 12:13 ` Erik Cervin Edin 2021-12-29 13:35 ` Andrey Butirsky 0 siblings, 1 reply; 6+ messages in thread From: Erik Cervin Edin @ 2021-12-29 12:13 UTC (permalink / raw) To: Andrey Butirsky; +Cc: git On a tangent, you can set up your own merge tools. So in git config you can add something like: [mergetool "both"] cmd = "sed -i -e '/^<<<<<<<$/d' -e '/^=======$/d' -e '/^>>>>>>>$/d' -- $MERGED" and call it with git mergetool --tool=both On Tue, Dec 28, 2021 at 10:50 PM Erik Cervin Edin <erik@cervined.in> wrote: > > > On Tue, Dec 28, 2021 at 9:44 PM Andrey Butirsky <butirsky@gmail.com> wrote: > > Thanks Erik, please post your further replies to the mailing list so > > others could see it also. > > Mea culpa > > > On a topic, > > I'm not familiar with Git code-base so don't know if it even possible in > > it's current architecture.. > > It looks like > builtin/checkout.c checkout_merged > is responsible and calls > ll-merge.c ll_merge > > I think other commands that allow merging strategies may use other > "merge drivers". > > From commit a944af1d86e6171d68ed2a3aa67b1d68f00e1fe8 > > merge: teach -Xours/-Xtheirs to binary ll-merge driver > > > > The (discouraged) -Xours/-Xtheirs modes of merge are supposed to > > give a quick and dirty way to come up with a random mixture of > > cleanly merged parts and punted conflict resolution to take contents > > from one side in conflicting parts. These options however were only > > passed down to the low level merge driver for text. > > It looks possible. > But perhaps the sentiment is that it's not adviceable? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts 2021-12-29 12:13 ` Erik Cervin Edin @ 2021-12-29 13:35 ` Andrey Butirsky 2021-12-29 14:51 ` Erik Cervin Edin 0 siblings, 1 reply; 6+ messages in thread From: Andrey Butirsky @ 2021-12-29 13:35 UTC (permalink / raw) To: Erik Cervin Edin; +Cc: git This is exactly what I tried to avoid, since Git already seem has all the needed under the hood to prevent such disaster.. On 29.12.2021 15:13, Erik Cervin Edin wrote: > On a tangent, you can set up your own merge tools. > > So in git config you can add something like: > > [mergetool "both"] > cmd = "sed -i -e '/^<<<<<<<$/d' -e '/^=======$/d' -e '/^>>>>>>>$/d' -- $MERGED" > > and call it with git mergetool --tool=both ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts 2021-12-29 13:35 ` Andrey Butirsky @ 2021-12-29 14:51 ` Erik Cervin Edin 0 siblings, 0 replies; 6+ messages in thread From: Erik Cervin Edin @ 2021-12-29 14:51 UTC (permalink / raw) To: Andrey Butirsky; +Cc: git On Wed, Dec 29, 2021 at 2:35 PM Andrey Butirsky <butirsky@gmail.com> wrote: > > This is exactly what I tried to avoid, since Git already seem has all > the needed under the hood to prevent such disaster.. It'd be neat if you could specify -X ours/theirs/both But I'm not sure I would describe the current situation as disastrous ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-12-29 14:52 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-27 12:52 request: allow passing -X <strategy-option> to git checkout <path> to auto-solve merge conflicts Andrey Butirsky [not found] ` <CA+JQ7M-By65FVPnMFnwE8zx3T4O7DV3_5Kf2P6eZhP4Zcemorg@mail.gmail.com> 2021-12-28 20:44 ` Andrey Butirsky 2021-12-28 21:50 ` Erik Cervin Edin 2021-12-29 12:13 ` Erik Cervin Edin 2021-12-29 13:35 ` Andrey Butirsky 2021-12-29 14:51 ` Erik Cervin Edin
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).