I created a repository with the name username.github.io (Used my username). Does the case (a-A) matter? I made it with lowercase letters then renamed it to the exact casing.
If I have to make the repository with the name "username.github.io", how do I setup multiple pages?
I'm going to http://username.github.io and I don't see anything.
According to the docs (step #5), the first time you do this it'll take a couple of minutes to show up. Also, you have to be sure that the name of the repository exactly matches your username on GitHub, including case.
For multiple pages, just make multiple HTML files (or whatever) in the root of your repository.
1-Beacuase of dns propagation delay it takes a while for your site to show up.
2-To create a page just create an html file in root directory of your repo. also you can create it inside any other path then you can access it via :
username.github.io/anyotherpath/page.html
3-You can also use jekyll which is static site generator written in Ruby.
Related
I do apologize if similar question already put, but I haven't found one.
I would like to change the default project description file name (called README.md) to be a custom name (let's say XXX.md) and I wonder if it is possible to be the XXX.md the initial readme file for the project (typical situation: you open the project Code page and you will see the content of XXX.md down at bottom).
I would like to verify if this approach possible in general, but I am mainly interested in Github and Bitbucket services. I briefly checked project settings and I cannot find there such customization. Is it even possible?
GitHub, at least, doesn't provide the ability to do this. It is possible to use a different format (e.g., README.asciidoc or README.rst), but the root file must be called README.
Note that you can include other text markup documents like this and they'll be rendered if they're visited, it's just that they won't appear at the bottom of the file listing like a README will.
First I build blog in hugo and deploy with netlify.
Verifying with file or txt, it isn't rendered in my case. I try to put content folder, also themes folder. So i found alternative way using google Web master center. And then, just add html tag. Finally, I got Verification completed. But, I can't use search console, yet. Because I'm not verified.
Why and How can correct?
If you want static content, rendered as-is, place it in Hugo's static directory and it will be added directly to the output public directory without alteration. Alternatively, you could use a meta tag to verify; just place that in your base layout; typically layouts/_default/baseofhtml.html
I was wondering if it's possible to have 2 Github urls that point to the same repository. The reason I want this is I posted a link to a repository somewhere where it is not possible to change my submission. Now I want to put the repository on my resume, but the repository name is so long that it won't fit on one line. I'd like to have a way to put it on my resume without breaking the original link.
The short answer is no: the GitHub URL is unique.
Your options are:
Work with the GitHub URL as-is (span multiple lines).
If your résumé supports HTML, use an href.
Fork the repository to your account, rename it with a shorter title, and put that in your résumé. Interested readers can click through the "forked from" link.
I'm planning to try using dokuwiki to manage my large collection of notes, and one of the major attractions is its flat file basis that'll allow me to edit via scripts etc. I had a question - suppose a page's material fits into multiple namespaces. If I were to create the file in one namespace and then create symlinks in the other namespace directories, would that work? Or would that screw up revisions etc?
Yes, you can do that. But yes, this will mess with your revisions a bit:
when DokuWiki saves a page, it copies the data of the old page to the attic
the name of the attic file is the same as the page that was edited, but with a timestamp appended
because new attic files are created you can't work with symlinks in the attic
Imagine you have the following setup:
data/pages/original.txt
data/pages/copy.txt -> original.txt
You now can edit the pages original and copy in your wiki and they will both always be the same. However old revisions of the pages will be split between the two, depending on which page you edited.
Instead of messing with file level consider
Include plugin to share content between pages.
Creation of some 'commons' namespace for such pages to be DRY.
Namespace templates (+ additional plugin).
Pulling content from page side instead of pushing it to pages. This might be good to start with. You can always include some php code or even write your own plugin.
I need to have a relative link to root of my repo from markdown file
(I need it working for any forks)
So it looks like the only way it's to provide a link to some file in the root:
the [Root](/README.md)
or
the [Root](../README.md)
(if it's located at /doc/README.md for instance)
At the same time I can refer to any folder without referring to a file
the [Doc](/doc)
But if I try to put a link to the root folder:
the [real root](/)
the [real root](../)
I'll have a link such
https://github.com/UserName/RepoName/blob/master
which unlike the
https://github.com/UserName/RepoName/blob/master/doc
refers to 404
So if I don't want to refer to README.md in the root (I could havn't it at all)
Is there any way to have such a link?
After some research I've found this solution:
[the real relative root of any fork](/../../)
It always points to the default branch. For me it's Ok, so it's up to you
PS
With such a trick you can also access the following abilities:
[test](/../../tree/test) - link to another branch
[doc/readme.md](/../../edit/master/doc/readme.md) - open in editor
[doc/readme.md](/../../delete/master/doc/readme.md) - ask to delete file
[doc/readme.md](/../../commits/master/doc/readme.md) - history
[doc/readme.md](/../../blame/master/doc/readme.md) - blame mode
[doc/readme.md](/../../raw/master/doc/readme.md) - raw mode (will redirect)
[doc/](/../../new/master/doc/) - ask to create new file
[doc/](/../../upload/master/doc/) - ask to upload file
[find](/../../find/test) - find file
You can either link directly to the file (../README.md), or simply use a full absolute URL to link directly to the repo root: https://github.com/UserName/RepoName
Using relative links doesn't work so well on GitHub. Notice the difference between the following two URLs:
https://github.com/UserName/RepoName/tree/master/somedir
https://github.com/UserName/RepoName/blob/master/somedir/somefile
Notice that the first points to a directory and the second points to a file. Yet, after the "RepoName" we have either one of tree (for a directory) or blob for a file. Therefore relative links between the two won't work properly. On GitHub, you can't use relative links to link between a file and a directory. However, you can link between two files (as both URLs contain blob). Therefore, if you wanted to link from somefile back to README.md in the root, you could do:
[README](../README.md)
That would give you the URL:
https://github.com/UserName/RepoName/blob/master/somedir/../README.md
which would get normalized to
https://github.com/UserName/RepoName/blob/master/README.md
However, if you just want to point to the root of your Repo (or any other dir), then it is probably best to use a full URL. After all, if someone has downloaded your repo and is viewing the source locally, the relative URL to the Repo root will be different than when viewing the file on GitHub. In that case, you probably want to point them to GitHub anyway. Therefore, you should use:
[root](https://github.com/UserName/RepoName)
Another advantage of that is that if your documentation ever gets published elsewhere (perhaps a documentation hosting service), the link will still point to the GitHub repo, not some random page on the hosting service. After all, the README at your project root is not likely to get included with the contents of the docs/ dir on said hosting service.
Perhaps it would help to understand how GitHub's URL scheme presumably works. I say "presumably" as I have no inside knowledge, just a general understanding of how these types of systems are generally designed.
GitHub is not serving flat files. Rather their server is taking the URL apart, and uses the various pieces to return the proper response. The URL structure looks something like this:
https://github.com/<username>/<repository name>/<resource type>/<branch>/<resource path>
The username, repository name, resource type, and branch are rather arbitrary and just ways to GitHub to ensure they are pulling information from the correct location.
The resource type matters as they are likely not pulling files from a working tree. Rather they are pulling the files/directory listings directly from the Repo itself through a lower level. In that case, obtaining a file is very different than obtaining a directory listing and requires a different code path. Therefore, you can't request a blob (file) with aresource path that points to a tree (directory) or visa versa. The server gets confused and returns an error.
The point is that GitHub's server works on a slightly different set of rules. You can use relative URLs to move around within the resource path part of the URL, but once you change the resource type in the resource path part of the URL, then GitHub's entire scheme is broken if you don't also change the resource type in the URL. However, browsers (or HTML or Markdown) have no knowledge about that and relative URLs don't compensate for that. Therefore, you can't reliably use relative URLs to move around within a GitHub repo unless you understand all of the subtleties. Sometimes its just better to use absolute links.