This required some code changes in the point of contact with the client
but nothing big.
A few TODOs were added as i was navigating the code, for instance:
- There's a 'meta' property of the search results being populated,
but doesn't seem to be used. Need to confirm
- The 'type' property of ES documents is looking at the class name, which
is not very OOP. We could easily change it. But this takes me to the last
point
- We are using ES 2.4.0, while the latest version is 6.X, in which
the 'type' property is deprecated and marked to removal. There are also
some query format changes, but since we are using basic queries, it should
be fairly easy (I started testing this work with a 6.X version).
If we are going to ES update, the 'types' property is going to be
removed anyway: https://www.elastic.co/guide/en/elasticsearch/reference/6.0/removal-of-types.html
* master:
Fix const reference
Add Heroku generated app.json
Remove REDIRECT and supporting code
Update uses of constants
Remove loading of constants from lib
Move lib/constants.rb to be under initializers
license: update years and authors
add "about this site" page
architecture: mention /download/win page-rule exception
add architecture document
Progit: make first edition translations disappear.
Remove uses of should
Use RSpec.describe instead of just describe
re run rspec `rails generate rspec:install` and update config
Bump uglify
Bundle update after rebase
Fix pg version
Fix uglify version
Bump gemfile
This patch adds an "about this site" page and links to it
from the footer (where we previously just linked straight to
the git-scm.com repo). This serves a few purposes:
- we lay out the relationship between the various bits of
site content. This clarifies the licensing, and
hopefully directs bug reporters to the right place.
- we credit Scott, who has moved on but without whom the
site would absolutely not exist in its current form
- it gives us a place to credit the companies that are
sponsoring us with resources
We only switched to /blog in 2013, so there's a real chance
that old links would use the bare format. And it's not that
hard to match them and give them the same redirect.
There hasn't been a blog post in 7 years, and there are no
plans to revive it. The existing posts generally fall into
one of two categories:
- news about the pro git book
- technical notes that weren't covered in the 1st edition
of pro git
The former are no longer interesting at all. And the latter
had their content folded into the second edition.
So let's drop this content, as we sometimes get issues
raised about its accuracy and formatting. We want to
redirect people to the actually-maintained book content.
We'll put a short note in the /blog route to help anybody
who follows old links to these posts.
Once upon a time, the idea was that you could update the
site with new book versions by posting to a special endpoint
with a secret token.
But these days we fetch the book material directly to the
rails environment by running a periodic rake task, and then
update the database directly. Let's drop this unused code.
We haven't been populating the database with this for some
time (and any residual records have been gone for almost a
year due to the database transition). And nobody seems to
have noticed.
Let's just give up on the feature in the name of simplicity.
These are historical names for things in /doc, etc. Let's
make them actual redirects so that people see the "official"
URLs (and we may eventually deprecate and remove these).
This currently generates a poorly formatted list of commands
with no actual links to the manpage. It was originally
referenced as part of a command index in a mock-up that went
away in the previous commit.
Probably nobody links to it, but we can easily just redirect
it to our good-looking link-filled command reference page.
Note that this lets us drop the redundant list of commands
in lib/constants.rb.
This is from an old mock-up of the book code. It doesn't
actually work (it returns a 500 probably because the
database schema has changed). The real endpoint is "/books",
so let's redirect there.
Once upon a time this was supposed to generate the `/docs`
index page, but it hasn't been used since b4fc467 (pulled in
jasons changes, moving to using his haml directly,
2012-03-29).
Let's drop it, since it creates hassle when updating the
command list.
I added Raygun support to get a handle on the exceptions we
were seeing due to timeouts in #1045. That's now reverted,
so the primary reason is gone.
Furthermore, the Intro plan only allows 500 exceptions per
month, and we exceeded that pretty quickly. Most of these
are just noise, so we may want to consider a service like
this after cleaning them up. But in the meantime, it's not
accomplishing anything.
The noisy exceptions seem to mostly be related to book
languages with broken links or incomplete translations. They
fall mainly into two buckets:
- dereferencing nil for various items. E.g., hitting
https://git-scm.com/book/sr/v1/%D0%9F%D0%BE%D1%87%D0%B5%D1%82%D0%B0%D0%BA-Getting-Help
returns the 500 error page.
- ActionController::BadRequest. E.g., hitting https://git-scm.com/book/ko/Git-%EC%EF%BF%BD%EF%BF%BD%EB%B2%EF%BF%BD-GitWeb
returns no output
We don't currently have any kind of logging or alerting on
unhandled exceptions. I'm experimenting with Raygun's free
"intro" plan so that I can at least get basic data like
"what exceptions did we see today?".
This just shows a list of the downloads pulled down from the
`download` task. Potentially useful for remote-admin, I
guess, but it falls far short of what's needed for actual
debugging (and I can't think of a single time when it would
have been helpful).
It also seems to cause rendering exceptions on the
production site when spam requests look at it.
Let's just drop it as ancient and not-useful.
This looks like debugging cruft added in 97bc298 (implement
ref version dropdown, 2012-04-17), and hasn't been kept up
to date (it tries to show the rebase page but doesn't
actually work).
This isn't a huge deal, but requesting `/test.zip` (which
some spam scripts do) results in an exception.
I'm not sure why the $SEARCH_INDEX_URL variable is used. It
does provide a layer of indirection, and the existing site
has both Bonsai and Searchify set up. So maybe it was for
switching between them.
These days we're just using Bonsai, so let's point it at the
variable that is automatically set up by the Heroku add-on.
pedrorijo91
Mark Tareshawty
Jason Long
Jeff King
Ævar Arnfjörð Bjarmason
chotuaashiq