pwdisswordfish5 44 days ago [-]
> With an internal repository, everyone in your enterprise will be able to view the Page with the same credentials they use to login to github.com

Public service announcement: "login" is a noun; as a verb, you should write "log in". (Consider "knockout" vs. "knock out".) Another thing to watch out for: writing "setup" instead of "set up".

rurcliped 44 days ago [-]
Microsoft apparently doesn't want "log in" to be used, and favors "sign in" instead: https://docs.microsoft.com/en-us/style-guide/a-z-word-list-t...
hunter2_ 44 days ago [-]
I can get on board with 99% of that as being stuff a style guide can reasonably standardize for organizational voice, but the one thing that doesn't sit well with me is preferring "in to" over "into" in the second example at the end: "Learn how to sign in to Power BI" seems like it wants to use "into" for the same reason we would use that compound word any other time it should be used.
kevin_thibedeau 44 days ago [-]
"sign in" is a verbal phrase. You can't merge "in" with "to" without losing its meaning.
hunter2_ 43 days ago [-]
Perhaps my grammer isn't as sharp as it should be, but I don't understand how "go in" would be any different. We say "please go in" and "please go into the room" without any issues, I think. What is fundamentally different between "sign in" and "go in" leading to this style guide not also discouraging "go into?"

I don't interpret a meaningful difference between "can not" and "cannot," nor between "any more" and "anymore;" thus, I don't find a meaningful difference between "in to" and "into."

tshaddox 44 days ago [-]
If you're fond of this rule and want to remember to follow it, just consider how you would write the past tense of the verb.
richdougherty 44 days ago [-]
Verb: LOG IN => - they LOGGED IN - the user LOGS IN - when LOGGING IN

Noun: LOGIN => - a LOGIN - some LOGINS

References: https://grammarist.com/spelling/log-in-login/ https://en.wikipedia.org/wiki/Phrasal_verb

hunter2_ 44 days ago [-]
Similar logic comes into play with mic (noun) and mike (verb). "They miked (or they're miking) the drums with several mics."

We avoid mic (verb) because the "k" works so much better than "c" when leading into various verb endings like -ed and -ing. It's the same reason we add "k" to the word traffic to form words like trafficking; we would interpret the "c" softly ("s" sound) if it was followed by a vowel. But in this case we replace it with "k" instead of adding "k" to maintain the long "i" which would shorten if followed by more than one consonant.

Mic (noun only) is great as a truncation of microphone, though.

rzzzt 44 days ago [-]
Login, logan, logun? I kind of like the idea.
jhardy54 44 days ago [-]
Nitpick: This works for "logged in", but not "set up".
chordalkeyboard 44 days ago [-]
“Set us up the bomb”
asidiali 44 days ago [-]
Is setting up?
jhardy54 44 days ago [-]
They said "past tense" whereas "setting up" is the present participle tense.
hanniabu 44 days ago [-]
Wow, thank you for clarifying this. I was actually wondering about this yesterday and just figured they could be used interchangeably but I also knew that in certain cases writing it a certain way just made more sense but I never knew the noun/verb rule behind it. I feel stupid now lol.
rjmorris 44 days ago [-]
And here I thought I was the only one who still cared about this, given how often I see it the verb form written as a noun. The English language evolves, however, and I'm coming to accept that this one is well on its way to being considered correct usage, so I'm doing my best not to let it bother me.
dataflow 44 days ago [-]
Also backup vs. back up.
impulser_ 44 days ago [-]
Does it really matter if everyone reading it understands it?
benatkin 44 days ago [-]
This is like saying that it's "start-up" and not "startup" 10 years ago.
OJFord 44 days ago [-]
No, it's like pointing out that you don't startup a startup, ten years ago nor now.
dataflow 44 days ago [-]
Both were always nouns though, right?
prepend 44 days ago [-]
This is really great news and I’ve been waiting for a while.

I use this extensively on gitlab and these little pages sites are easier to use than markdown.

However one thing that’s cool about GitLab is that we host it internally so any “public” site is available to anyone on the intranet without needing to log in. So the project sites started getting read by lots of users who don’t have GitLab logins and would never commit to a repo.

I wish there was a way to link my orgs logins with GitHub so non-GitHub licensed users could view the sites. I mean, I can do that but I have to then buy GitHub licenses and make them create GitHub accounts just to view project docs. That’s pretty expensive compared to just keeping projects on my internal GitLab.

codazoda 44 days ago [-]
This. When I read the title I was really excited. All of my GitHub users can already access private wikis. It's nice that I can now publish a site to those same users, but I'd like to write docs for the non-technical users at my company without making them public. It would be nice if I could restrict a site to people on my company VPN or, better yet, an IP range.
johannes1234321 44 days ago [-]
VPN and IP won't help - the trend is too move out of VPN. A big threat is always internal and byod opens up the intranet to all risks from the outside.

The solution needed is to allow oauth-style authentication of corporate users.

osgovernment 44 days ago [-]
Setup a gateway to do this or host your own GitLab. GitHub Pages uses a shared IP. Blocking based on IP would require them to rework their infrastructure.
bewuethr 44 days ago [-]
To clarify, this only applies to GitHub Enterprise – great for intranet sites. If you are on GitHub Enterprise.
theptip 44 days ago [-]
That's annoying. As far as I can tell this is a free feature in GitLab, and it's one of the ones I miss after moving back to Github.

https://docs.gitlab.com/ee/user/project/pages/pages_access_c...

petepete 44 days ago [-]
Ah damn, got excited by the headline for a moment there. Thought we'd have another excuse to switch away from Confluence.
beckingz 44 days ago [-]
Look forward to the day when GitHub pages and sharepoint sites can be one and the same.
prepend 44 days ago [-]
One of my big fears is that Microsoft will merge this kind of stuff into SharePoint. SharePoint is probably the best example of ruining and making something that should be simple horrible, and complex, and stupid, and poorly functioning.

All it needs to be is a wiki. Instead it requires layers of admin and stuff 5000 settings that don’t work. And it’s really expensive.

wjdp 44 days ago [-]
Been using the same feature on GitLab for quite a while for publishing code coverage reports.
sn1de 44 days ago [-]
Baffling that this wasn't a day one feature. Doubly baffling that it now launches on Enterprise only with no guidance on if or when it will be generally available. Never an explanation why this couldn't have been there all along. You have it with the repos already. It almost seems like you would have to go out of your way not to have this baked in from day one. I'm a long term fan, but c'mon github, you're better than this.
jrockway 44 days ago [-]
I'm not that baffled, I guess. I would assume Github pages work something like "compile to HTML, push to a CDN" whereas Github itself queries a bunch of data from a database, reads the Git repo itself, etc. -- it's not a static page that can be served from a CDN, the page is generated by an application. Therefore, in the repo case it is easy to check authorization among the other things the page generation code does, whereas for static pages, there is currently no application code that runs for every request, and so no place to put an authorization check.

Obviously you could make the Github Page load a dynamic page that checks auth, but I guess they wanted scalability more than they wanted features, and that's what we arrived with.

TL;DR: I'm not that baffled. If a feature isn't in the spec, you shouldn't expect an implementation that makes it easy to add that feature.

dtech 44 days ago [-]
You can still put a static page behind authentication, it doesn't have to immediately be a dynamic page with database interaction.
jrockway 44 days ago [-]
I agree; you can easily have an authenticating proxy. Like I said, I'm guessing that they decided it was a static page on a public CDN first, so now it's hard to add an authenticating proxy on each CDN node. If they wanted auth from the start, then it wouldn't be a static page sitting on a CDN node, and it would be easy to add. (But harder to scale to a CDN, and thus we'd see a lot of Github Pages sites slashdotted or whatever.)

I could easily be completely wrong about this. But it's interesting, to me, to consider the order that features were requested, and how that affects future feature requests. Sometimes you paint yourself in a corner and make easy things hard. Something to think about as you plan your own software!

teraflop 44 days ago [-]
If you ask me, any page whose behavior depends on the currently logged-in user's identity, including the list of groups they're a member of, is not "static" in any meaningful sense.
hunter2_ 44 days ago [-]
Most people use "static" to mean that there is only one version of a response body. I guess denying access is technically a second version of the response body, but that's kind of a stretch because the layer where the body lives (ok, the two bodies: one for 200 and one for 403) doesn't need to be capable of business logic (like conditionals, db queries, etc.) during the request/response cycle. It uses them in perpetuity without tailoring them to the session.
cratermoon 44 days ago [-]
You can put an image behind an login. The page or whatever content that's behind the auth wall doesn't even even have to be aware of that wall.
arvindamirtaa 44 days ago [-]
This is wonderful news to host sensitive internal documentation without bending over backwards. Too bad it's only for enterprise accounts.
ngrilly 44 days ago [-]
Too bad it’s only for Enterprise and not Teams.
tumblewit 44 days ago [-]
I'm not sure if this feature exists on github or i couldn't find it but i would like to have my github pages repository private and the blog public which is possible with gitlab.
josepmdc 44 days ago [-]
You can do the same with GitHub. Until now GitHub pages are always public even if the repo is private.
tumblewit 44 days ago [-]
i see thanks
foo123456789 44 days ago [-]
What I would like to have is to make the repo of my github page private, but have the page still be visible.
cratermoon 44 days ago [-]
Hasn't gitlab had this since they started?
abhinav22 44 days ago [-]
This is great news