Correction: Event logs should be transaction logs instead and you must be able to travel through it reverting and re-applying actions. It should be branch-able and allow you to jump between those branches.

I can do that with Emacs. What other tools make it easy to branch in history?

For small values of easy: vim. (It is really easy to do I think, doing it correctly instead of just being clumsy and hitting some key that starts it, that is the challenge ;-)

I only learned now that emacs could do it.

I didn't know that vim could do this! I've always assumed that undo/redo (u/^r) were my only options.

For anyone else who didn't know, try ":help undo-branches" or take a look at https://vim.fandom.com/wiki/Using_undo_branches , which has a simple example of use.

GIMP.

This is one thing it does very well, it beats emacs hands down in history visualization (at least without undo-tree, I've never tried it).

Emacs branching got way better with undo-tree, check it out :-)

I feel like from a design and architecture point of view, building an application with the command line as a first class citizen will ensure that the application is well designed.

It ensures separation of concerns is at least minimally applied in order to support two separate presentation layers (GUI & CLI). CLIs are also much more testable in general, so usually it’s easier to write e2e tests if a CLI is present. It might not cover 100% of the code because it doesn’t test the GUI, but does often get you something substantial like 90% of the way there.

It depends on the application, but CLIs can make testing GUIs easier in two ways:

- you can test the rendering layer in isolation by using the GUI to display two pieces of information manipulated by the CLI and comparing the renders, eg blank screen -> add some object.

- you can comparison test the GUI, eg pressing button X produces the same result as CLI option Y.

Properly testing a GUI requires having an internal CLI, in places I’ve worked — eg, app companies.

Have you ever run `rm -f important_doc.txt` instead of intended `rm -f important_doc copy.txt`?

It doesn't matter if it is GUI or terminal interface, software must be _humane_, forgive mistakes and provide a way out. As much as love Unix coreutils and have them in may fingertips, those are the least humane programs I have ever used.

Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover.

> Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover.

You have to earn it. I admit that when I started using git sometimes I made a copy of the repo just in case I ended in a state that made it easier to nuke it and start again

"cp -a" was definitely a huge boon to learning git. Fear-free experimentation is a wonderful thing.

A copy of the repo really? I just check in everything in a new commit then write the SHA1 somewhere.

The point of taking a copy of the repo is that you don't have to use git itself to get back to a known state, which is important when it's a tool that you're experimenting with and you're not sure on its use.

There's also a psychological element to it. If you can verify for yourself that the repo can't possibly contain anything that would mess you up after an earlier mistake, it's much easier to do things than if you have to worry about using the wrong branch name when you don't know how to delete branches, for example.

I totally agree, as long as that interface gives users knowledge as to how it forgives the user.

I use a Mac for work, and one of the first things I did was to alias `rm` to the utility `trash`[0] -- instead of immediately marking the bytes as free like `rm` does, it'll move the file(s) to the system's trash can.

[0]: https://hasseg.org/trash/

Yeah, user facing filesystems should be change-based, and require elevated permissions to permanently delete data.

The problem is that filesystems don't get enough love. There are plenty of more fundamental problems that aren't going anywhere, so do not expect this to change.

It implies that the application is made up of commands, which leads to a healthy separation of concerns.

I'd take a bit less of an absolutist standpoint myself, but, designing your application so that it has this event log (Command design pattern from back when, but I'm sure it has a more modern name nowadays) and its functionality is separated from its user interface are best practices.