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

[olsen232]

As far as I know, using kart resolve --renumber theirs should work even if there are other conflicts? Unless there are schema conflicts, which I think have to be resolved first. But ignoring schema conflicts: if you have 10 conflicts, you have to resolve them before you complete the merge, but you can do so in any order. Running kart resolve --renumber theirs should resolve as many conflicts as it can using the renumbering logic... the remaining conflicts you have to resolve yourself, but you can do so before or after.
Is this what you observe? If not, can you show what Kart does that prevents you from using kart resolve --renumber whenever it would help you?

There shouldn't be any issue with stepping the sequence ahead to a different PK value to avoid conflicts. Ideally, Kart would help you do this somehow, perhaps let you generate random PK's, or... not sure really how else Kart would choose a good non-conflicting PK for you, which is why this isn't done