GitHub doesn't show search field unless you sign in
web.archive.org
web.archive.org
Github used to have an awesome and public way to explore projects (http://web.archive.org/web/20130730125837/https://github.com...) - I remember using it a lot to look for projects to learn to read code because it allowed me to easily find projects by language. They replaced it with a flashier, but in my experience, much less useful tool that you have no control over - https://github.com/explore .
I know I'm not the only one thinking of moving my repos to another provider or perhaps a self-hosted solution because of this direction.
Not quite sure if I understand which specific thing you are mentioning, but does https://github.com/trending happen to be what you want?
But if gitlab jumps the shark like github is doing we can always have anyone in the ecosystem selfhost a clone, albeit we would need to reimplement all the enterprise features people want.
Secondly, they do have proprietary features, embrace, extend, extinguish style.
see also https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
The only thing I can think of is patches via email, but that's just using no repository at all.
But apart from sending changes via email (which is actually a very good way to go for small(ish) changes--actually, it is so good, the Linux kernel developers use exactly that: git can generate emails that are both human-readable, so you can easily review and comment on patches, but also can be imported automatically into a repository by the recipient), you can just send pull requests via email? You simply put into an email the URI of your git repository, wherever it is hosted, and the recipient can pull from it. That is the power of an open distributed system like the internet.
And to spin this a bit further: Actual "hosting" isn't even necessary technically. Especially once we get rid of IPv4 and NAT, it should be trivial to spin up a git server instance on your workstation (or maybe your smartphone, as that probably is online 24/7) so people can pull from there. Whether that is practical? It well might be--but my point is more to show what is technically possible.
And yes, all of that was possible with a "previously popular solution"--git existed before github, obviously, and its popularity is what caused github. Also, all of that applies just the same for other distributed SCMs, of course.
DDOS scripts create new sessions on every attack request. It's a very hard problem to solve without blocking legitimate traffic too.
Simply sign your session ids with an HMAC, to verify the id without any I/O! And require something expensive to create a session (such as a hash-based challenge request). Sessions are usually not needed for static sites, so by the time the person searches, their browser will have earned one session. A spammer on the other hand wouldn't have the computational power to create the various sessions. Also, if a spammer's IP is detected, the computational complexity can be increased for that IP.
I don't understand why one would DDOS Github. What is the reason for that?
http://arstechnica.com/security/2015/03/github-battles-large...
http://fiatjaf.alhur.es/gh-browser/
It adds links directly to GitHub source code (to other GitHub repos or external documentation) whenever it finds import/require statements.
> Treat nonlogged in users as second class citizens. By always giving logged out always cached content Akamai bears the brunt for reddit’s traffic. Huge performance improvement.
I have ended up using this philosophy in a website I've been working on lately, where people can post puzzles from The Witness. This includes simplifying decisions such as not tracking solved puzzles unless you have a user id, and not allowing navigating to a random puzzle either, as this routine depends on stored solves and upvotes. Supporting not-logged-in users just means extra code for me.
In general, I don't think this is a bad attitude for a website to have.
It is perhaps different in the case of GitHub, a highly depended-on and well established website which is actually removing functionality here. I would still assume good faith about the reason. And mobile login rates are a problem for everyone, I'm pretty sure, not just GitHub.
However the search inside a repo is missing now and using site: to search inside a repo doesn't seem to work with Google.
machine that doesn't necessarily have a github account or is not logged in.
I use 2FA and it's really disruptive to force a login when your intention is to perform a few quick search requests.
And as the screen shot below shows, you don't need to be logged in, to search a repository.
To make the long story short, you can install our indexing engine on low cost platforms like $10 VPS plans from DigitalOcean/Vultr or on dated hardware like a 6 year old Dell laptop:
http://gitsense.github.io/blog/benchmarking-march-14-2016.ht...
It is an interesting case study in UX - the difference between a great experience and an awful one can come down to a single, well placed search box.
What is GitHub's rationale behind this jarringly awful, blatantly bad decision?
Unfortunately it does let you escape common characters that are common in code, doesn't give you the option of maintaining white space/line breaks in your query, doesn't let you search in other branches.
This is a serious regression.
Off-topic: @dang, can we get a "Upvote this comment if has less than 1 point, else don't upvote it" button?
The font-color of the comment (aside from links already visited) should be enough to indicate if it has positive or negative karma. Individuals can decide whether to upvote or downvote further at that point.
I'm not sure it's still happening. I think it stopped the people who provide corrective upvotes.
This is by far the biggest problem I have with HN. If there's not enough light in the room, I have problems differentiating between shades of grey/black if the contrast isn't high enough. And it makes downvoted-to-hell comments extremely hard to read because all the mobile apps seem to replicate this, and you can't just ctrl+a to add contrast.
Yes, this is true. However, consider a comment with 0 points. If two HN visitors see it at roughly the same time, and both upvote it, it will have 2 points, rather than one point. What's more, neither visitor will see the effects of their action until at least one page reload and some time has passed.
Honestly, it makes Github feel much more like those vaguely-shady we-won't-tell-you-anything-substantial-until-you-give-us-an-email-address-that-we-can-sell-to-our-"valued partners" websites.
That's... not really the direction you want to be heading in when you want to be known as a stable, reasonable place for widely-used projects to be hosting their source code.
Github's mobile experience has been pretty bad in general. their mobile view doesnt even have the primary feed D: Instead it has a "repositories you contribute to", which is probably the most useless thing I could imagine for a logged-in view.
Yesterday, I tried finding my own issue that I submitted two minutes ago to update it with a screenshot from my phone. Had to type in the full URL manually at the end.
I love being able to quickly edit my notes from my phone, but no, I have to revert to the desktop version to be able to edit the file.
Not being able to see my feed is definitely a huge disadvantage.
All in all, I use the desktop version quite a lot. At least it's easy to switch to it.
!github some-repo
What's the next step? Cloning only allowed for logged-in users?
Since I commit and fetch repository data using SSH and a private key, I rarely (if ever) log into the GitHub UI
I guess I see only down-sides from a user perspective - what are the upsides for GitHub? Tracking?
For example: https://www.google.com/search?q=monty+python+site:github.com
I run a site (http://petihacks.com) with many of these little tricks if it's the interest of anyone
Doing search well is computationally hard. More than that, it's next to impossible to cache for because there can be so many variants. All-in-all, it's the ideal sort of system to attack if you want to DDoS somebody.
Making people sign in is a tiny barrier to entry that stops anons hammering their system with uncacheable search requests.
Yes, there's probably also a business-marketing argument that goes into this but if that's the sort of trade-off we need to keep Github free for open source, indefinitely, I'm all for it.
And again, this is still free so stop being babies. If you don't like it you're very free to clone the repos out and search them yourselves. Want your anons to be able to search your stuff? Host it yourself and manage your own DDoSes.
Not only does this make the search cheaper and easier for the guests (just an index of public repos, so no permissions involved), it makes it easier to continue offering search to authenticated users whilst being able to mitigate L7 DDoS on the authenticated search (just block the users involved in the attack).
Besides, there is a huge SEO benefit to having a searchable and discoverable interface, and a huge attention retention benefit to keeping users on your site to search once they have arrived there. On top of that, Github understand their data structures better than a search engine so it's easier to tune complex searches just for a codebase, or blog, or issue.
There's really no benefit to hiding search, and having written many community generated content sites the only reason I would hide search is as a stepping-stone to making the content part of a walled garden.
It's fairly inevitable Github will want to do this, I imagine they're looking at the number of users who are not signed-in or on free accounts as yet to be monetised. They would want more activity data to make arguments for advertising, or recruitment monetisation, or plan up-sell, etc.
That's where this makes sense, as a way to gather more user habit data.
Google at one point gave you a lot indicators to which pages people were landing on and why. Now all that information isn't shared with site operators, so it's impossible to qualify statements like "internal searchable interface lead to more Google search traffic".
Maybe it was true previously, maybe it was true even last month, but is it still true with the latest Google update---no one can measure.
1. Search is just not hidden in GUI for users, who are not logged in, but these users can still perform search as other people mentioned in comments
2. Github Search is definitely cached
3. It has nothing to do with DDOS. Do you expect Google requires you to sign in in order to prevent DDOS? Moreover, unless Github is totally wall-gardened, there are tons of ways to DDOS the service. I suggest you need to learn how DDOS actually works.
2. No disagreement that searching for the same thing can be cached. But that's not the problem. Search for "banana" "banana 2" "banana 3", etc. It's very simple for a botnet to hit a search function like this with unlimited variance, making it impossible to cache against.
3. You think that Github and Google receive the same revenue benefits from providing a free search?