1

does anyone know a git custom merge strategy for golang styled files with the column-format of the go-stylesheet?

situation

Assume having a struct like this:

type Foo struct {
    Bar bool `json:bar`
}

now two branches are modifying this struct:

branch A:

type Foo struct {
    Four bool `json:four`
    Bar  bool `json:bar`
}

branch B:

type Foo struct {
    Bar    bool   `json:bar`
    Sixsix string `json:six`
}

actual result

When I now try to merge/rebase these branches, I get obviously a conflict because both branches modified the line defining Foo.Bar.

expected result

I am searching for a custom merge strategy which results in a well formatted struct with merging the conflict automatically.

type Foo struct {
    Four   bool   `json:four`
    Bar    bool   `json:bar`
    Sixsix string `json:six`
}
blaimi
  • 749
  • 5
  • 14

1 Answers1

2

Nobody can prove it's impossible, but nobody's found a way so far either, it's high on everybody's wouldn't-it-be-nice list and lots and lots of people have tried very hard.

Touching adjacent lines often means further changes need some touchup that can't be predicted without knowing the semantics.

For a demonstration of why it's hard, consider values that can be iterated in two orders, or elements in a list with a unique primary key.

abc,1

the two tips

abc,1
def,2

and

ghi,2
abc,1

should be merged as

ghi,3
abc,1
def,2

or maybe with that 2 and 3 swapped. Or whatever. Nobody's ever found a way Git could know this at all, let alone one that's easier than just fixing it manually (which takes like two seconds once you've got some practice).

jthill
  • 55,082
  • 5
  • 77
  • 137
  • Any quick and dirty way to fix it "manually" – apples723 May 23 '23 at 02:03
  • Another possiblity: 1,2,4 because they're bitmasks. Git simply cannot know this stuff. Restricting the conflicts to detected adjacency is just the setting that keeps mistaken auto-accepts very very rare, a wildly common (and, btw, perfectly correct) new-coder practice is adding new values adjacent to the ends of lists (like, if not after the existing last value, then before the trailing end-marker) and that prompts questions and answers like this one. – jthill May 23 '23 at 02:54
  • This is a classical conflict which cannot be found by git. And yes, you are right, for the merge strategy I'm searching, knowing the semantics is necessary. E.g. weblate provides a very complex strategy for gettext-po files (https://github.com/WeblateOrg/weblate/blob/main/weblate/examples/git-merge-gettext-po) – blaimi May 23 '23 at 07:03