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@xxxxxxxxxxx> wrote: > > > On Tue, Dec 28, 2021 at 9:44 PM Andrey Butirsky <butirsky@xxxxxxxxx> 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?
