New mistake of the day

Today, I made git commits on no branch. I didn’t know it was possible, but apparently so! It happened when I opened a second shell of the directory I was working in, and I assumed that it would maintain the branch information. It didn’t.

I managed to make a merge back in, but I had to use GitX (a GUI for git) to do it. I have no idea what the syntax is for telling git to merge from (no branch). I tried it just like that, but got an error for having parentheses unexpectedly. I opened GitX to take a look around, and the first thing I selected in the tree history (sorry, can’t recall what it was) threw an error and took me to the commit window to resolve my conflicts for the merge. Of course, I had to do the actual edits for the conflicts in my usual editor (MacVim), and then GitX forced me to run the commit from the command line, but at least it got me started and off of my no-branch purgatory!


About joanwolk

3 things I like: theater, food, geekery. 3 things I don't like: clichés, blisters, coffee.
This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to New mistake of the day

  1. Daniela says:

    I got in that situation once before, but I just ended up remembering what my changes were and throwing those back in. Did you check out a specific commit or something? I think that puts you outside of branch-land.

    • joanwolk says:

      Yes, sort of. I *pulled* a specific remote commit, in an attempt to clean up after a couple of mistakes. If I’d checked out a specific commit, Isaac told me it should have given me a warning, but either I missed it or I didn’t get one for pulling a commit.

      What I should have done (it turns out) was a git reset HEAD~N, where N is the number of commits back I wanted to go. See the fantastic entry on git reset at In this case, I would have probably run it git reset --hard HEAD~N, because I also wanted to ditch all the crap in my working directory and start fresh, but be careful with --hard, which is one of the only ways you can actually lose your work within git, precisely because it will clear your working directory and anything not committed will be gone.

      • Daniela says:

        I haven’t seen the git reset HEAD~N thing, that’s cool. In general, when we check out a commit it’s to run a spec to see if it was broken yet at that point/test behavior in earlier builds so we like getting the commit from the logs as opposed to “number of steps back”. I’ll try to remember the “proper” way for my own stuff if it plagues me in the future 🙂

      • joanwolk says:

        If you’re looking at when something broke, you should investigate git bisect. It’s pretty much exactly the thing for debugging. I haven’t used it yet, but Yitz is a big proponent of it. 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s