I recently had an issue in one of my Git repos, and decided to drop all my local changes and just pull down from the remote. This post looks at what I did.
Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers. You can see all posts on Git as well.
A Bad State
The old cartoon looks like this:
In my case, I hadn’t done this. I didn’t have a fire, but I did leave the building.
Actually, what I’d done was made a few changes at home and hadn’t committed them. I was in between trips and in a hurry, and walked away. On the road, I made similar changes and did commit/push them. When I got home, I couldn’t git pull because of the conflict.
What’s worse, these were binary (Excel) files.
I could have tried to sort things out, but in this case, I knew the remote copy was likely more up to date in place and I could easily re-enter the data I’d saved but not committed.
The way to do this for me, for tracked changes, was git reset.
In my case, I wasn’t trying to reset to a particular commit, I just wanted to whack all changes I’d made. This was just one file for me, so I issued:
git reset -–hard
The -–hard discards changes to any tracked files. Changes to untracked files aren’t affected. I’ll write about that in another post.
This cleaned my local repo back to the last time I’d had a git pull. From here, I could just get changes from the remote and work on.
SQL New Blogger
This post took about 5 minutes, literally, to write. Some of that is I’m a good typist, some is this is a simple story. Any tech pro ought to be able to do this in 5 minutes as well. If not, learn to type or to structure a short story.
This shows a little tech knowledge, but also an explanation of a situation.