Month: March 2017

How to view a git log graph from the command line that looks like Visual Studio View History – 076

It feels like there are 100 different ways to do a git log. Here’s one possible way… I’m using the OpenLiveWriter repo to demo since it has lots of branching going on.

P.S. The way to exit these log commands is to press ‘q’ when the colon appears, if you are following along at home.

let’s start with git log –graph.

git log --graph command line

But it’s too wordy to show the graph.

Let’s try git log –graph –pretty=oneline

git log --graph --pretty=oneline

Better, but the long commit IDs are throwing everything off.

Let’s try git log –graph –pretty=oneline –graph –abbrev-commit

git log --graph --pretty=oneline --graph --abbrev-commit

And that’s about as close as I can get to a graph that looks like the graph in Visual Studio.

If you know of a better way, please share with the group! 🙂

How to open files in a repo that doesn’t contain a solution in Visual Studio 2015 – 075

tl;dr if you have a repo that doesn’t have a solution, don’t worry. You can still use File – Open – File to open files associated with the repo and Team Explorer will still track those files the same as if a solution were open.

P.S. I’m writing these tips for VS 2015. I’ll need to update for Visual Studio 2017.

For all my adult life (minus 2 years), the Solution file was your go-to starting point in Visual Studio. Even if you create a new text file via File – New – File, Visual Studio creates a new Solution nevertheless.

a solution still appears

It’s almost like Visual Studio has a Solution that’s in search of a problem.

Can’t believe I’ve never thought of that one before… Anyways…

Repos that do not contain a Solution

If you open a repo that doesn’t have a solution in it, you’ll see the following:

no solution found

You can still go to File – Open – File and open files that are associated with that repo. In fact, File – Open – File will open to that repo’s folder.

Opening a different Solution when Team Explorer is connected

A solution will always take precedence over a repo opened in Team Explorer.

For example, in the previous screenshot, I have a repo named “amend” that’s open, but this repo doesn’t a Solution. If I open a different solution that does not contain a repo, you’ll see that Team Explorer goes offline.

Team Explorer Offline

I guess this is Team Explorer’s way of saying, “Hey Look, I don’t want you to get confused which solution is tied to which repo.”

Switching to a different Repo with a Solution Open

Now having said that, let’s suppose I’m connected to a repo that has a solution, let’s say some ConsoleApplication54 project (you know you have them!) and you have the ConsoleApplication54 solution opened.

If you switch repos (via Team Explorer – Manage Connections) to any other repo, regardless whether it has a solution file opened, you’ll be in an odd state. On one hand you’ll have a solution opened, but Team Explorer will be tracking changes for an entirely different repo. This is the state you couldn’t get in to in the previous section.

It’s almost like a Game of Thrones battle (or so I’m told – haven’t seen or read yet) being played out inside the IDE: solutions vs repos.

How to amend changes to your code in your most recent commit – 074

Yesterday’s tip was about making changes to your commit message. Today’s tip is making changes to your code as well.

Hey my Git experts friends reading this! I’m not sure what the command line equivalent is, so can someone look at my section below on using the CLI and tell me why I have to use –allow-empty?

We’ll start with Team Explorer in Visual Studio and then rinse and repeat with what I think is the equivalent git command.

Amend using Visual Studio

It looks like Team Explorer will let you amend based on whatever changes are in the working directory, but just in case you only want to change one file, I’d suggest staging the file(s )you want to amend first. In a command line scenario, whatever files are in staging are the ones that will be amended. (See previous tips)

Actions button in Team Explorer

Click on the Actions button and select Amend Previous Commit.

Amend Previous Commit

And you’ll get a new commit ID.

new commit ID shown in TE info bar

Amend using Command Line

Full disclosure: I don’t know when to use the –allow-empty option. I also don’t know what the ramifications of using it are. It seems I need to use this option even though 1. the staged changes are different than those in the commit history and 2. I’ve specified a commit message. TBH I’m not sure what is going on here.

But this is my best guess at the command line equivalent of what Team Explorer is doing.

  1. make changes to your file
  2. use git add to add those changes to staging
  3. git commit –amend -m “new message” –allow-empty or git commit –amend –allow-empty (but I’m not sure)

The below screenshot shows what happens when I don’t use the –allow-empty option.

git commit --amend -m "new message" wants the --allow-empty even though changes are staged

and here’s what happens when I use the –allow-empty, which turns out to be the behavior I want (or as far as I know!)

git commit -m "update readme" --amend --allow-empty shows success

So yeah, if you know what is going on wrt to the –allow-empty option, please let me know!!

How to amend your most recent commit message on your local repo from the command line – 073

Following yesterday’s tip where you learned how not to panic when presented with a vi editor, today’s tip will cover the scenario of what if you wanted to amend your most recent commit message.

Suppose you had a git commit message “updating readmeee” which you’ve caught immediately. The most straightforward way is git commit -m “new message” –amend

git commit -m "updating readme" --amend updating last commit message

But let’s say you forgot the message flag and now you’re now face-to-face with the vi editor.


star wars it's a trap meme

When vi first opens, your cursor will be in command mode, despite seeing the cursor in the editor. (pssst… it’s a trap)


You’ll want to press The status bar at the bottom will change to show —Insert–


Once you are finished with your edits, hit ESC to enter Command Mode, and then press :wq for write and quit.

and voila, you’ll see in your log that your last commit message has been modified, but the timestamp (and rest of commit history) is still the same.


How not to quit your career when Git opens a vi editor – 072

There’s a joke, “How do you generate a random string? Put a Windows user in front of vi editor and tell them to exit.” Credit to Aaron Jorbin.

Suppose you’re doing research on the git commit –amend -m “some message” command and you forgot the -m “some message” part.

Everything spins around and suddenly I’m elsewhere…*

vi editor - one of the scariest images a Windows user will ever see

I’m in a sandy beach on a tropical isle.

Actually, you’re in the vi editor. Before you start typing anything, stop. Get up, stretch your legs. Odds are you’ve been at your desk for way too long anyways 🙂 Get some coffee and come back and search google what to do before you start typing.

If you are like “Say Yoho! SAY YOHO!!!*” to get out of here without making any changes, you’ll want to hit ESC and then type :q! Don’t think about it. just do it.

typing in the command :q!

You can verify in the git log that the amend had no impact.

*The reason I got into computer programming was because of Scott Adam’s Pirates Adventure text-based adventure game for the TI-99 4A Home Computer. As a 6 year old, it fascinated me how a computer could understand some English commands (get safety sneakers) but not others (open refrigerator – you are in a kitchen after all!) “Say Yoho!” was the command to jump to a different part of the island. Say it too many times in a row and you’d die (I think). Never beat the game as a kid, but later in college, I downloaded an emulator and finally got past those crocodiles!

How to undo changes to a file that has been staged in Visual Studio – 071

Almost always, every answer on SO for “how to undo changes to a file in Git…” starts with “well, it depends on what you mean by undo changes.” I’m starting to see why all these answers start by clarifying what you are trying to do.

Personally, there seems to be two cases where I want to “revert or undo” from staging:

  1. I’ve accidentally used git add . and added files that I didn’t mean to add to staging
  2. I’ve changed my mind on whatever code I was writing (e.g. the code didn’t do what I wanted, or more likely, never compiled) and want to pretend I never wrote it in the first place because I forgot to create a branch first

How to unstage changes in Team Explorer

Right-click on the file you want to remove from staging and select the Unstage command.

Unstage command in TE

And Team Explorer will put it back to the Changes list. You can confirm this in the command line as the file will be listed under Changes not staged for commit.

If you’re going for the destructive “let’s never speak of this code again” option, follow yesterday’s tip by right-clicking on the file and selecting the Undo Changes… command.

How to unstage changes in Command Line

Rinse and repeating for the command line, let’s stage our commit using git add Program.cs and confirm it using git status. Although git never says “staged”, you’ll just have to translate “Changes to be committed” to “These changes are staged to be committed”

git status showing a staged Program.cs

Now to unstage the changes, you can read the instructions in the git status (see above).

Running git reset HEAD Program.cs puts it back as an modified file that hasn’t been staged yet.

git reset HEAD program.cs provides feedback

Wow! Git actually provides feedback with this command. You see in the message above unstaged changes after reset. I’ll never understand why Git decides to give feedback on some commands and not others.

And doing one more git status will show you the commands to fully remove the changes, although destructive.

git status showing how to revert or undo changes to file in working directory

And lastly doing a git checkout — Program.cs will undo all changes to that file to the last commit.

command prompt showing nothing to commit

How to undo all the changes to a specific file in your working directory using Visual Studio – 070

I always love Git documentation that includes warnings about destructive commands (like this one) because there’s no way to get this code back (aka a data loss scenario), unless the code happens to be in your favorite editor’s buffer or you still secretly use Ctrl+C Ctrl+V for emergencies – DONT JUDGE ME PEOPLE! =p For example, from unmodifying a modified file

It’s important to understand that git checkout -- [file] is a dangerous command. Any changes you made to that file are gone – you just copied another file over it. Don’t ever use this command unless you absolutely know that you don’t want the file.

I think to myself, “Um, Git, you know the code I’m writing… there’s a reason I never want to speak of this code again!!” It seems Git was designed for people who never have to StackOverflow with cut and paste attempts just to get something to compile and yet forgot to try on a throwaway branch first. It’s once I get it to compile I want to start over as if to convey in my logs, “yep I knew what I was doing all along…”

tl;dr – Today’s Git tip of the day is when you’re feeling, “um, yeah, let’s pretend that never happened.”

Undo changes in specific file in working directory using Team Explorer

In Visual Studio, let’s add a few lines of code in our Program.cs project and hit save. You’ll immediately see Team Explorer telling you that you have unstaged changes in your working directory. Note that I say “unstaged changes” and not “uncommited changes.” Remember, even though Team Explorer lets you jump over staging, there’s still a “middle layer” as seen in the past couple of tips.

Right-click Program.cs and click Undo.

Undo Changes command in TE

Now you’ll be prompted “are you sure” because like the Git documentation says, you won’t be able to get these changes back.

Are you sure VS prompt

Now we’re back to before we made any unstaged and/or uncommitted modifications. Even VS seems to know to pop these changes from its clipboard ring. Wow, I feel for whoever had to test those scenarios!

Undo changes in specific file in working directory using Command Line

I believe this is the command line equivalent of running git checkout — <filename> although I’m not sure what the actual underlying plumbing Team Explorer is doing.

If we want to rinse and repeat from the command line,

First, make some edits in Visual Studio and hit save. We can confirm these changes by doing a git status

git status shows Program.cs modified but not staged

Next we’ll run the dangerous (aka data loss) command git checkout — <filename>

 git checkout -- Program.cs

Although Git is like “Meh”, Visual Studio grabs your attention immediately with the old-faithful FILES HAVE CHANGED FILE HAVE CHANGE OMG FILES HAVE CHANGED WHAT DO WE DO?!?! dialog.

Files have chnaged. Reload in VS? dialog

Since we made these changes from the command line, Visual Studio needs to know what to do with the current text buffer. In this case, we purposefully made these changes, so we want to say Yes to All.

And we’ll see that we’re back to our baseline code and no more changes being tracked in Team Explorer.

There are no unstanged changes in working directory in TE

and Git from the command prompt confirms it.

nothing to commit, working tree clean

Aside: What if you had said “No” or “No to All”?

Well, I guess Git won’t be aware of what state your file really is in. If you try to git add or git commit the untracked changes in Program.cs, Git will ignore you. Literally. Git says “nothing to commit, working tree clean.” Team Explorer will also do the same by not giving you any options. But as soon as you hit Save in VS (even if the file is already saved) or even type another character in the text buffer, Git picks back up on the changes.

I guess the take-home message is to hit Yes to All. If you have a scenario where you’d want to say No to All in such a situation (perhaps making this “less dangerous” although there are many, many better ways), please let me know!