Short Update: The issue was closed. In the end the problem is build out of two issues. One - the line order - was already reported and will be fixed. The other one - the changed UUIDs - is a feature, not a bug KiCad is checking if there are duplicate UUIDs and increment one in case there are identical UUIDs found. That’s good, BUT: Why are there duplicate UUIDs if KiCad will check it?
Well, i think we have to do some “homework” first, to answer this question. Get a clean project state without identical UUIDs and observe under which circumstances the issue eventually arises again. I hope we will not find anything again, but if so, I will give you an update.
duplicate UUIDs are usually there if groups/sheets etc. are duplicated with copy and paste. Not sure why they are not updated on saving right after tho.
If I place no_connects they seem to get the same UUID - at least in my example. I’ve attached a simple test case. One can see two elements with the same UUID in the second commit (line 50/51 in sub1.kicad_sch). I did not change anything by hand nor did I copy these elements. Obviously the check on duplicated UUID failed in this case. Only at the second “save” operation KiCad changed the UUID.
The good news: It’s somehow deterministic and it should not cause merge conflicts. But just in case - a workaround would be: A Close - Reopen - Save routine in front of each push. This will at least prevent masking of unintended changes.
Can anyone tell me if this topic is worth a new bug report?
KiCad is checking if there are duplicate UUIDs and increment one in case there are identical UUIDs found. That’s good, BUT: Why are there duplicate UUIDs if KiCad will check it?