I stick with the way GNC is designed -- take turns to use it from a shared location -- rather than expose my financial data in this manner and be left with nothing. This is way out of my safety league despite being in the field of IT for over 30+ years! There is a reason why it is xml based file and not plain text based one. Of course plain text based one can be easily "stitched" together unlike xml one, which should not be.
-----Original Message----- From: Raymond Maass <[email protected]> Sent: Monday, August 31, 2026 11:42 PM To: Gnucash Users <[email protected]> Subject: [GNC] Risks of merging xml save files Hi, all. Loving Gnucash -- thanks so much for all the development and maintenance to help make it what it is. TL;DR -- Are GUID's for elements (e.g. transactions/splits) in the xml-formatted save files generated and used such that they are required to be anything other than simple unique identifiers? I'm not sure if this makes sense, but I'm worried that, in addition to being unique identifiers, they may also serve as some sort of check-sum for consistency like I believe git commits do. A few more details: I'd like to be able to have my wife and me both able to interact with our joint gnucash file via a hosted git repository as a way to (a) track history with a bit more detail than the auto-generated backup files (b) allow us to both work on the same file So far, I set gnucash on our two separate computers to each save as xml without compression, making the git diffs quite readable and enabling merge conflict resolution to merge changes back into the main branch when conflicts arise. When we have both done some basic work (e.g. entering some transactions), and then want to merge our files, it is generally a relatively straightforward process of making sure all the transactions in the xml file are present in the resulting file. We could also update the transaction count that is stored in the file, but I've found so far that leaving that not updated doesn't seem to cause problems (making me wonder what it is there for). I've done a few basic tests where I take a simple file and carry out that workflow, then reopen the merged file in Gnucash. So far, the result always seems to be as expected with all separately entered transactions present. So my question is whether anyone sees any potential issues with this. One particular worry that came to mind is about the GUID's in the file. Each transaction and sub-component like the split lines has a GUID. When I merge the files, I simply copy the corresponding lines for each transaction into the merged file with whatever GUID was made on the branch. Are the GUIDs generated and subsequently used in any way that might cause consistency problems later such as a checksum of the save file at the state they were added? Or am I okay as long as they're all unique, even if they were generated and manually merged from, effectively, two different gnucash files (from branches)? Bonus question: Is there a particular algorithm for generating valid GUID's, or can they be any (unique) valid string with the allowed characters? I'm somewhat interested in the idea of programmatically adding elements to the xml file, and this would be a consideration in doing so. Thanks, Ray _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
