[GNC] Risks of merging xml save files

[John Ralls]

The only file-sharing mechanism I’d recommend is a shared directory on a local computer. Any remote-storage service like Dropbox or Google Drive has too much latency for the file locking mechanism to be effective.

Jim’s right about git not being a good choice, but his illustration wasn’t great: You’ve already observed that the transaction count isn’t very important. A greater risk is that if you and your wife separately enter similar transactions a git merge might try to merge them into a singe transaction with only a few scattered lines like the id elements flagged as differences.

The only safe way to modify a GnuCash data file is to use GnuCash’s API, either from C, Python, or Scheme.  All of the data integrity checks are in GnuCash code. There are none in the SQL formats so it’s no safer to modify a SQL book than an XML one with external software.

Regards,
John Ralls


> On Aug 31, 2026, at 22:36, Patrick James via gnucash-user <gnucash-user at gnucash.org> wrote:
> 
> While I suspect that it's possible to stitch XML files together, this is not something I recommend.
> 
> What I do recommend is exporting the transactions using the CSV export tool from one and import into the permanent book.
> 
> 
>> On 08/31/2026 8:41 PM PDT Raymond Maass <raymondbarrettsmith at gmail.com> wrote:
>> 
>> 
>> 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
> gnucash-user at gnucash.org
> 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.