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! |