Hacker News Reader

Comment by rectang | Hacker News Reader

What I really want to see is a blog post on Git as an undo engine.

This is related to the idea of using Git as general storage, in that the undo history can be persisted, and then reconstituted by a new process. The trick would be to make all actions compatible with conversion to and from a commit.

View on HN

Emacs kind of has this in the form of magit-wip-mode. It doesn't sync with the undo system but it does persist every file save event since the last "real" commit.

I need to look into this.

Just yesterday I lost some work (only maybe 10 minutes worth) when I was updating my org notes. I staged some files, committed them, but made a typo in the commit message. I ended up reverting the commit when I meant to amend. Then I discarded the the staged reverted changes and noticed the status said I was still reverting. So I looked up the command to get me out of that state. I ran 'git revert --abort' and it blew away my unstaged changes. Ah well, those versioned backups I have Emacs do are going to save me this time, or so I thought.

If you did actually commit, you should be able to find the changes on the reflog

In magit, it's accessable from the log menu

Create a branch, reset it to the badly worded commit hash and then you can try to ammend again.

I was breaking a bunch of unstaged changes into two commits, and the part I lost had not been committed.

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.

one of these years i'll have something fun to show you

Reply on news.ycombinator.com