I've seen programs that serialize the undo manager, but is there an advantage to using git instead? I suppose it does most of the work for you, but you'll still need to manage actions that can be undone but don't directly modify a file (these are entirely app dependent, but could be something like changing which tab document is selected).
The advantage is that Git's data structure is an open design, with existing tools able to introspect and possibly manipulate it, with potential users and contributors able to leverage their existing knowledge, and with documents/projects still being parseable decades from now.
I have dreams of implementing an music composition tool / audio editor with a line-oriented edit-decision-list (EDL) text file format that where changes could map coherently onto git history. Ideally, that EDL format would be an open standard as well: I've contemplated the Pure Data file format and AES31 as possible candidates. This is just at the conceptual stage, though.
One problem with git is that it assumes you have some sort of "diff" utility for before and after snapshots. For some types of things, that's not feasible - you can't easily diff two images and work out what filter was used. Sometimes you instead you want to create the diff, and generate the "after" snapshot. You could emulate this by stowing the information somewhere hidden and writing a fake "diff" that simply retrieves it - but saving the edit tree and reconstituting it is supposed to be git's job! You end up reimplementing bits of git, just to make git work.
I suppose the "diff" limitation would constrain the potential use cases. For my purposes, I don't think that would be a problem, because the project format would consist of two types of files:
• PCM audio files which are captured once and then never modified.
• Line oriented text files for which the traditional "diff" functionality suffices.
