Suppose you notice a typo in your repo description or you didn’t specify one at the time you created the repo. To the far right, you’ll see an edit button.
Clicking this button allows you to edit a description and a website URL.
Give it a little while, but your repo description will end up on the GitHub.com search page when you do.
I’m sitting here wondering, “is this a useful tip?” but then I remember that feeling I felt when I (finally) found how to do it. Originally I thought I had to update a repo file somewhere, since it took me a while to get used to what files GitHub’s UI gets it’s info from (e.g. license) and what files are metatdata for the GitHub repo itself.
Not only does the color bar show you a breakdown of language usage percentages, these labels are clickable!
In my random-example repo, if you click on the VB 16.5% (or whatever it might be by the time you read this), you’ll see
Now you can filter all files in repo based on language without needing text in the search bar.
If you ever want to quickly drag and drop files to a repo (perhaps you’re a speaker at a conference and want to share your slides for your sample code), you can use the Upload files button that’s on the far right of the repo page.
A wild drag and drop box appears! (sorry, that was a terrible pokemon go impression.)
Now you can drag and drop your files into the box. Note that as you drag files, you’ll see them queue up. (Could you technically call this queuing up in staging? Conceptually you could call it staging, but I doubt that’s what’s happening under the hood). Sorry, I digress…
and volia, there was much rejoicing!
Note you might say, “Wait a sec… how is this added but yet the repo bar is still a single solid green color?
Good catch! You might have to wait a minute or so and refresh. Today I had to wait a couple of seconds and then a couple of minutes. Check out the support page if you’re having any issues.
And remember, Linguist, the open source project that displays these language percentages, is accepting contributions!
As you saw from previous posts, the UI on GitHub.com allows you to specify an optional extended message.
If you fill this optional extended description out,
you’ll see your extended description comments behind the `…` ellipsis.
Clicking the ellipsis shows the optional extended description.
How to do add the extended description from the command line
I’ve looked at a few stack overflow answers. There are answers using two -m arguments, using a literally formatted string (i.e. the ‘$’ at the start of the string), and using a vim editor. This also works for other editors I’ve played with.
For my examples right now, you’re watching me use Git Bash (i.e. Git Shell as setup from Desktop for Windows – I’ll cover more about Desktop for Windows in the upcoming tips).
Using the two -m arguments approach,
and pushing that up to GitHub, you’ll see the optional extended description under the ellipsis.
Old SDETs never die! What if I added 3 -m arguments?? What will GitHub do?
Looks like each extra -m adds a newline in the optional extended description, as shown on GitHub.com.
In the previous examples, you saw how to create a new file in the root directory. But suppose you wanted to create a new file in a new directory.
Follow the same steps as before by clicking the Create New File button. Then in the Name your file… edit box, type your folder name, and then hit a forward slash (the / since it leans forward) .
If you need to rename the new folder, press backspace until you backspace over the forward slash. Then you can retype the name of the folder.
Sometimes when I’m typing in an edit box, I’ll continue to hit backspace even though there’s nothing left to delete. I like that squeaky-clean feeling I’ve deleted it all. But if you’re like me and you’re thinking the cursor will just blink at you at the beginning of the file name edit box, yeah, you’re going to be in for a bit of a surprise. As I mentioned above, hitting backspace at the beginning of the file name edit box will deleted the forward slash, so you’ll now be editing the folder.
A 3-legged dog walks into a bar and says, “I’m looking for the man who shot my paw!” It’s one of my favorites.
And yes, I’ve started experimenting with animated gifs. Where was Snagit back in 2008 when I did the VS Tips? Oh yeah, that’s right. It sat unused because I refused to give up my MSPaint keyboard shortcuts. Hopefully I’ll strike the right balance with animation on the page without too much motion!
Sometimes I’ll create a new file, but the Preview doesn’t render the markdown and shows everything in plain text instead. And I’m left scratching my head :confused:
If you find yourself in this situation, look at the file extension for your new file (or lack thereof).
Simply add a `.md` to your filename, and now your Preview will work!
BTW if you get a “can’t edit” icon when you try to add the `.md` to the filename,
this is is because you are still in Preview mode. Click on the Edit new file tab to the left of the Preview and you’ll be able to edit the filename.
And Lenny Bruce is not afraid.
Suppose you have a file that you want to edit in a repo. Similarly to creating a new file, you can also use the UI on GitHub.com to edit a file.
Click on the file you want to edit. In this case, I’ll edit my penultimate FAQ.md file.
On the page where you can view the contents of the file, to the far right side, there’s a pen icon button to Edit this file.
Clicking on Edit this file will put you in the edit UI, similar to the add new file UI.
And just like in adding a new file, you can specify what the commit message should contain and where the commit should go, either current branch (e.g. master in this image) or a new branch.