Document how to resolve `uv.lock` merge conflicts

[zanieb]

I don't know what best practice is here.

[LennyN95]

I came across this problem. We found that the lock files may differ greatly across branches during active development and that it's usually to complex for automatic conflict resolution. However, it seems more plausible to generate the lock file after merging branches rather than before.

What first came to my mind was to avoid pushing local lock files and create them as part of the CI pipeline on the main branch before running the tests, and commit the lock file when all tests pass.

[zanieb]

In brief the current recommendation is:

• Attempt to merge the parent into your branch, encounter a merge conflict in the lockfile
• Checkout the lockfile from the parent git checkout <parent> -- uv.lock
• Lock again uv lock

[BenGale93]

I find that the most common source of conflict is the version number of the package itself. Easy to deal with but generates conflicts when it doesn't really need to. Is there any plan to mitigate this?

[zanieb]

Are you using a dynamic package version or does it just change a lot?

[BenGale93]

Good point, I'm picking up the version number dynamically from the git tags. I assume it's impossible to avoid this issue and keep git tags as the single source of truth?

[BenGale93]

Just found https://github.com/astral-sh/uv/issues/7533 which covers it. Sorry for wasting your time @zanieb!

[zanieb]

👍 yep that's the issue to track. No problem :)