How to deal with new features in concurrent branches without conflicts

[enricofer]

Describe the bug I'm not sure if this is a bug or a feature, but, working with branches, there is a behaviour on primary keys that is nasty and imply unnessary conflicts resolutions. When working on many branches you edit workingcopy adding separately some features they get the same auto_pk because they acquire the same serial field initial value of the original branch from wich they originated. When you merge these branches to the original branch you will have a conflict caused by same auto_pk values and resolving the conflict I can't keep all the incoming changes but I have to choose between "theirs" and "ours". In my application I'm solving this manually stepping ahead the serial that drive auto_pk field creating the branch, updating at the same time the same serial of the original branch. But I have not verified yet if this trick has consequences or caveats. Digging in merge command help I found a "--renumber [ours|theirs]" parameter that

              Resolve one or more insert/insert conflicts by keeping both ver‐
              sions ("ours" and "theirs")but assigning one of the two versions
              a new primary key value so it doesn't conflict  with  the  other
              Option is mutually exclusive with with_version, file_path.

But this force anyway to manually solve other conflicts before applying this resolution so automatic resolution is excluded

To Reproduce

download test repository: PKISSUE.zip that contains a main repo. Unzip and enter command line.

Merge first branch MOD1 that contains a new feature with auto_pk = 1 kart merge MOD1 and you will get:

Merging branch "MOD1" into main
Fast-forwarded to c37c77c6e086ee342f3249e6c78394ac73601485
Updating PKISSUE.gpkg ...

now we try to merge "MOD2" that contains another different new feature with auto_pk=11 kart merge MOD2 and you will get:

Merging branch "MOD2" into main
Conflicts found:

a0102036_Consulte:
    a0102036_Consulte:feature: 1 conflicts

Repository is now in "merging" state.

but there is no conflict because I want to keep all two new features. so I have to apply --renumber param

kart resolve --renumber theirs
kart merge --continue

to have the correct result: But In this case I have to manually solve other real conflicts before to go on with --renumber

Expected behaviour I would expect to merge the branches wit concurrent edits without any issue

**Version Info **

• OS: linux
• Kart v0.13.0, Copyright (c) Kart Contributors » GDAL v3.6.3; PROJ v9.2.0; PDAL v2.5.3 » PyGit2 v1.12.1; Libgit2 v1.6.4; Git v2.38.1; Git LFS v3.3.0 » SQLAlchemy v1.4.45; pysqlite3 v2.6.0/v3.40.1; SpatiaLite v5.0.1; Libpq v15.0.3 Executed via helper, PID: 1915035