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 [off-list ref] wrote:
quoted
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.?)
From: Erik Cervin Edin <hidden> Date: 2021-12-28 21:51:09
On Tue, Dec 28, 2021 at 9:44 PM Andrey Butirsky [off-list ref] 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?
From: Erik Cervin Edin <hidden> Date: 2021-12-29 12:13:49
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 [off-list ref] wrote:
quoted
On Tue, Dec 28, 2021 at 9:44 PM Andrey Butirsky [off-list ref] wrote:
Thanks Erik, please post your further replies to the mailing list so
others could see it also.
Mea culpa
quoted
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
quoted
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?
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