Hacker News Reader

Comment by fodkodrasz | Hacker News Reader

The inability to conveniently version control/differentiate/combine its database caused me to drop it after a data loss (not caused by GnuCash, but HW problems), when I had only a few month old backup and a corrupted current GnuCash savefile.

I have tried beancount (like ledger but in python) since, and I'm all into plain text accounting since. Also the UI of GnuCash always felt clunky and a bit incomprehensible at places.

View on HN

I store the .gnucash file in git, and after editing things in Gnucash I run a script that exports[0] it to a hledger file in the same directory and commits both. So `git show` gives me a readable view of what changed, but the accounts are still usable by non-nerds.

[0] https://hledger.org/gnucash.html

Asking as a hledger user: why do you still use Gnucash, is it only so that you can have a UI?

FWIW, I started playing with something that felt like more of an 'app' experience with Beancount with 'Beancolage' so you could have plaintext accounting integrated alongside a reporting UI: https://github.com/seltzered/beancolage

It's still an early concept though, but at the end of the day it's a vscode-like experience so aspects like git are just an extension away.

It's for the UI, yes, since they're not my accounts, I'm just tech support for them ;-) I've seen there is an hledger-web, but there's a bunch of reports and workflows already set up in Gnucash and switching would involve learning new things and I'd rather spend as little time as I can on accounting and taxes. (OTOH adding a script to enable "git log -p" took like ten minutes.)

GnuCash can keep around multiple backup copies, making a new one every time you save.

Look for files like:

    <yourgnucashfilename>.<timestampnumber>.gnucash

    <yourgnucashfilename>.<timestampnumber>.log

Also note that your GnuCash file is just a single gzip'd XML file, and not too big. You could store it as-is in Git, or you could have a script/filter to gzcat it first, so you could store deltas/diffs and maybe use less space.

While it is true (i didn't have that kind of backups for some reason back 10+ years ago), getting the intact bits of that xml from a corrupted zip file is not trivial. Also diffing/manually editing xml is not great fun in my experience.

There's also a setting to turn off the gzipping. I use that to make it Git-friendly.

I agree version control would be nice. I guess you could use the XML storage format and then use git? Personally I use the sqlite format and just back it up every time I make changes.

The plaintext alternatives like ledger and beancount seem like they lend themselves more naturally to version control.

You're 100% correct. My ledger git repo has 1300+ commits (about 0.8 per day on average).

Reply on news.ycombinator.com