Tag Archives: git

History v. State

I want to reprogram the way I think about the state of my data models.

Think of a blog post. Before I publish it, it's unpublished. After I publish it, it's published. If I unpublish it, it's unpublished again. Maybe I edit it and republish it. Published again.

I (and a lot of programmers, I think) tend to think of a thing like a blog post as having a state. Maybe in the MySQL database, blog posts are in a posts table having a state or status column. It's an ENUM type, probably.

But state is really just whatever the most recent change represents. Like git -- state is like HEAD. And too often, I don't think about saving the history of states when I should.

So, resolved: consider whether any new data model having a state or status should instead (or also) have a history.

New git alias: git last

I made a new git alias I'm loving. Maybe you have something similar.

I've added this to my .gitconfig:

[alias]
    last = rev-parse --abbrev-ref @{-1}

This gets the name of the branch you had checked out prior to the current branch. It's like git checkout -, but you can use it all over, such as:

$ git merge `git last`