Gentoo Archives: gentoo-portage-dev

From: Matt Turner <mattst88@g.o>
To: Junio C Hamano <gitster@×××××.com>
Cc: gentoo-portage-dev@l.g.o, git@×××××××××××.org
Subject: [gentoo-portage-dev] Re: [RFC PATCH gentoolkit] bin: Add merge-driver-ekeyword
Date: Thu, 24 Dec 2020 04:47:39
Message-Id: CAEdQ38En=HrG9A0STgaxFAwqxBjwNGQoV=U26Pia3x=gd-Attg@mail.gmail.com
1 On Wed, Dec 23, 2020 at 2:46 PM Junio C Hamano <gitster@×××××.com> wrote:
2 >
3 > Matt Turner <mattst88@g.o> writes:
4 >
5 > > I want to handle conflicts automatically on lines like
6 > >
7 > >> KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86"
8 > >
9 > > where conflicts frequently happen by adding/removing ~ before the
10 > > architecture names or adding/removing whole architectures. I don't
11 > > know if I should use a custom git merge driver or a custom git merge
12 > > strategy.
13 >
14 > A merge strategy is about how the changes at the tree level are
15 > handled. A merge driver is given three blobs (original, your
16 > version, and their version) and comes up with a merged blob.
17 >
18 > In your case, you'd want a custom merge driver if you want to handle
19 > word changes on a single line, because the default text merge driver
20 > is pretty much line oriented.
21
22 Thanks, that makes sense. The merge driver I've written seems to work
23 great for handling the KEYWORDS=... line.
24
25 If users could more simply opt into using it (e.g., on the command
26 line rather than enabling it via ~/.gitattributes) I think it would be
27 fine to use. Better yet, is there a way git can be configured to
28 fallback to another merge driver if the first returns a non-zero
29 status due to unresolved conflicts? For example, if there are changes
30 to other lines, how can I fall back to another merge driver?
31
32 Thank you for your advice!