We keep getting merge conflicts with vendorlib-sbom.json

11
Every time we commit, we encounter merge conflicts with "vendorlib-sbom.json". This situation is quite frustrating, as resolving these conflicts requires the use of an IDE (we use Visual Studio) and an external Git client (our choice is GitHub Desktop).   While this is annoying for us, I can imagine that for those without experience in Git, it could be a significant obstacle.   Does anyone have any suggestions for a permanent solution to avoid manually fixing the JSON file each time?   It could be an option to add "vendorlib-sbom.json" to .gitignore, but I don't know if this has any unwanted consequences.
asked
5 answers
10

Hello Jeroen Wijnholds,

 

Everyone is facing this issue right now, I overcame this by changing "vendorlib-sbom.json merge=sbom-merge" to "vendorlib-sbom.json merge=studiopro" in project>vendorlib>.gitattributes. No issues still now.

 

Hope my answer helps. Reach me out for any queries.

answered
2

What we found (Mx 10.6.3) is that de vendorlib-sbom.json gets regenerated every time we start StudioPro. This file is however not ordered/sorted. Which means that we sometimes get a change in vendorlib-sbom.json although nothing has changed. Its only the sorting which is different. This leads to unnecessary commits and merge conflicts. On some developer laptops the sorting is completely different. I could not find an gradle option to force sorting of the sbom.

For now we added this file to the .gitignore list.

answered
0

Had the same issue with a project near the time someone downloaded a speech-to-text module.

None of the both workaround mentionned in this thread solved the problem.

 

It worked when the person who succeeded commiting last sent his vendorlib sbom JSON, and we replaced our with it. I don't know what are the implication for later since we are beginner with use of team server as team.

answered
0

i had same issue, when moving the vendorlib-sbom.json to a backup folder, it got recreated by Studio Pro when re-opening the project mpr file again.

I think it is safe to move it to a backup folder and get it recreated. 

answered
0

Hello @jeroen

Even I was facing the same issue while taking a pull from remote repo,

To confirm, did you commit your changes locally before you pull from the remote repo?

Please note that Git will not allow you to directly pull (using git pull) if you have uncommitted local changes. While technically possible, forcing a pull with uncommitted changes using commands like git pull -f is strongly discouraged.

Thus the suggestion from my side is to

1, commit the changes locally

2, Take pull and it will ask to re base or merge

3, go with rebase and it will solve the conflict for vendorlib-sbom file.

4, once done Push your changes to remote repository.

 

That's how it worked for me.

answered