Month: February 2017

How to press ‘y’ to navigate to the permalink for a file’s exact commit ID on – 052

Suppose you had a question about the contents of a file at an exact moment in time (or in git-speak: at an exact commit in time). If you were to visit the repo and navigate directly either to a file or the line in question in a file, e.g. showing the line


you might forget or not even realize (like me) that you’re copying the link for the latest version of that file on master (or in git-speak: the version of the file at the current head of master).

In other words, if someone were to come along and make a change to this file, your link to this line of code at the latest commit on master might be a link to a totally different line of code instead of the openDevTools() link.

Press the `y` key and you’ll see that the page seems to refresh. Well, yes and no. The page has updated, but look at the URL now.

now you got the permalink to that exact line of code!

This shortcut is the functional equivalent of clicking Code – Commit – Browse the repository at this point in the history – clicking the file (e.g. main.js) – and then clicking the line number.

This shortcut works for any branch name, specific commit SHAs, and tags, according to the docs. E.g. suppose you were looking at main.js on a branch called windows-fix located at and you pressed the `y` key. The URL would change to

I hate not having a photo to go alongside a tip, so here’s a picture of a Great Dane next to a small (terrier?) dog, aka how I feel standing next to tall people.

Great Dane standing next to small dog

photo taken from

How to view the name and email that is associated with a commit on GitHub via the web browser – 051

Suppose you want to verify your email in your Git logs hosted on GitHub without pulling down the repository.

Navigate to the desired commit (via Code tab – Commits link – Commit)

commit displayed on github

Now in the URL shown in your web browser, add the extension .patch and you’ll see the name and email from your .gitconfig.

printout from a format-patch displayed in plain text

btw, in case you want to know what’s going on, this is actually the git format-patch command, where GitHub is displaying the output.

Since the commit ID is 32473a3, we can do

$ git format-patch 32473a3~1..32473a3

git format-patch 32473a3~1..32473a3

to get the same result in the command line.

showing generated patch file from command line

How to hide your email address in your Git commits but still get contributions to show up on your GitHub profile – 050

I have good news and bad news. Let’s start with the good news.

If you want to get credit for your commits, but don’t want to expose your GitHub email address in the commit logs (have you checked the logs? why haven’t you checked the logs*?), here are the steps you can take. 

contributions graph on GitHub profile

First, in GitHub go to Settings – Email – Keep my email address private

Keep my email address private checkbox

You’ll notice a new email for you to use for your Git commits.

Next, you’ll need to update Git to use this new noreply email instead of your real one. You can do this either from the command line or from GitHub Desktop.

From the command line, provided that you want to change your email address globally across all repos, you’ll simply do

$ git config –global “”

and then to verify, type

$ git config –global

for example

git bash showing --global changed

Or if you want to use GitHub Desktop, it’s just at Options – Configure Git which will do the same as the –global flag, hence the red circle around the global gitconfig message.

Configure git username and email address

You can read more in the GitHub Documentation for keeping your email address private, e.g. how to change only a specific repo, etc.

And now for the bad news.

This change will only apply moving forward. If you’ve been using your personal email address in previous Git commits, you’ll need to do some work to scrub the logs (where possible). Check out the GitHub Documentation for changing author info.

*My favorite all-time scary movie is the 1979 version of When a Stranger Calls. Well, not the entire movie, but just the first 15 minutes. And I don’t think it holds up anymore with smart phones being the norm. But wow, that was something scary! And yeah, you should check the logs… just to make sure you don’t have your email address committed that you don’t want others to see. 

How to use to shorten GitHub URLs and create vanity URLs – 049

Suppose you want to shorten the URL to a particular location on GitHub. Or perhaps you want to create a vanity URL that goes directly to your GitHub profile, e.g. You can use GitHub URL Shortener.

To shorten a URL, open your favorite command prompt (via Git Shell) and type in

$  curl -i -F "url="

in the response, you’ll see your shorten URL!


To create a vanity URL for your GitHub profile,

$ curl -i -F "url=" -F "code=saraford"

in the response, you’ll see a new way to refer to your GitHub profile!


How to add a license to a repo (and have it be recognized) for an existing GitHub repo – 048

In yesterday’s tip, you saw how to select a license when you create a new project. Today’s tip is about how to get that license picker back for an existing repo.

Since licensing is done based on the content of a file named license in your repo, instead of metadata about the GitHub repository that lives alongside the repo, first, you’ll want to create a new file in your repo.

Create new file button 

Next, type in License and over to the right, the license dropdown button (re)appears. You can call the file license,, LICENSE, or LICENSE.MD, as long as the filename is “license”


When you select a license, for example the MIT License,

Choose a License: MIT License

and you’ll see that the license text is inserted and some boilerplate information, like copyright year and name, are inserted.

MIT license showing copyright year and full username

Now when you commit this file (and wait a minute or so), you’ll see that GitHub now displays the license name at the top of the repo.

MIT license displayed at top of repo above language bar

Suppose you didn’t choose a license via the dropdown picker (either on /new or in the method described above). Suppose you’ve previously pushed a license file up to GitHub at some prior point.

GitHub uses an open source project called Licensee to do license detection, i.e. compare the license file to the list of licenses coming from the Choose a License website. According to the GitHub blog, “Licensee is the same code we use to provide the Licenses API and understand how repositories on GitHub are licensed.”

If you want to contribute to licensee, there’s a contributing guide in the repo. If you’re looking to add a new license that can be detected, you’ll want to check out the choose a license repo.

How to add a license (and choose your own licensing adventure) when you first create a repository on GitHub – 047

For the longest time, I thought it was required that you select a README in order to select a license. Although you should have both (ideally) in your repo, you don’t have to create a readme file on the /new page just to set a license file.

In the image below, the Initialize this repository with a README is unchecked, while the MIT License is being selected for the Add a license dropdown button.

adding MIT License without the Initialize this repo with a README checked

Remember, just like a readme, the license for your GitHub repo is only a file that’s within the repo itself (and doesn’t automatically get added to a Visual Studio solution – something that took me a long time to wrap my head around).

LICENSE file shown in repo file listing

But suppose you know you need a license, but want to go over what your options are. There’s a (?) button right next to the Add a license dropdown button on the /new page.

choose a license help icon

Clicking on this help icon button will take you the Choose a License website, a “choose your own adventure”-style site where you can learn more about licensing!

Got a suggestion for the Choose a License website? The website (a github pages site) is an open source project accepting contributions!

Down in the bottom right corner of the footer, you see a link to the repo

Curated with <3 by GitHub, Inc. and You!

I call out this link because adding the “and You!” link was my first ever Pull Request. These Pull Request-related tips won’t really click until you’ve walked through submitting a Pull Request yourself. I hope by sharing my lightbulb experiences from my first few PRs that it will help others get a sense of what the process is like.

How to automatically close Issue(s) when you push a commit to GitHub – 046

You might have discovered this feature accidentally if you’ve ever pushed a fix up to GitHub using the magic words in your commit message. The story goes: You’ve committed a fix and pushed it to GitHub. Next you go to the Issue to close it, but to your (pleasant) surprise, the issue is already closed! How did it know?

I put pleasant in parenthesis because I hate technological surprises. I mean surprises are good, but I want to know what caused the surprise, so I’ll know how to surprise myself again in the future!

Two things must be true for your commit message to close an issue (see GitHub help article)

  1. contains a deviation of the words fix, close, or resolve, immediately followed by #<issue-number>
  2. the commit is on the default* branch (which is master by default, unless you or a repo maintainer has changed it)

If you take away nothing else from this tip, take away this: do not try to use the word Issue, e.g. Fix Issue #3 Otherwise, it won’t work. Gets me every time.

For example #1, suppose you have a repo where you want to delete a file that isn’t being used. You or someone else has created an Issue to track this work.

Delete Class1.cs #3 issue on github

You’ve fired up Visual Studio**, deleted the file from solution explorer (and saved the .csproj so the reference to the file is gone), and opened up the Team Explorer – Changes window to commit the change. You can type in “Fix #3” as the commit message to close Issue #3 in your repo.

commit message: Fix #3

Now when you return to your Issue, you’ll see it has been automatically closed with references to the commit automatically added to the Issue timeline.

Delete Class1.cs showing as Closed with how closed messages added to timeline

Now let’s say you are like me and after years and years and years of habit (and we’re talking about habit since the good ol’ days of RAID – where my MSFTies at!?!?), you put the word Issue in between the Fix and the #3. The Issue won’t get closed and you’ll have to close it manually.


And yes, as this blog post title implies, you can close multiple Issues.

For non-VS users out there, let’s do a command line example. Let’s say you have two Issues out there on your repo on GitHub. I’ll use close this time***, but close(s|d), fix(es|ed), or resolve(s|d) will all work.

git commit -am "Close #4 and Close #5"

*We’ll talk more about default branches later, but if you want to confirm the default branch, go to the branches link above the language bar in your repo.
**As if I could keep myself from blogging re Visual Studio Smile This is a Windows-first, non-Windows friendly blog, meaning I’m doing everything this from a Windows point of view. At some point the series will contain lots of Windows-only tips, but for now, I’m trying to straight the right balance in being non-Windows friendly.
*** In the command prompt example, I edited a readme file. I’m using the shortcut -am to do both the git add and the git commit at same time. More on these shortcuts later!