* 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
* 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).