gh-ost VS Git

I’ve been through multiple incidents where everything worked fine in the testing environment but ended up locking the production database for minutes when deployed. A category of open-source tools called OSC (Online Schema Change) exists to mitigate such pain, like gh-ost used by GitHub and OSC used by Meta. They work by creating a set of "ghost tables" to apply the migrations, copy over old data from the original tables, and catch up with new writes simultaneously. When all old data is migrated, you can trigger a cutover to make the "ghost tables" production. Check the post below for a great introduction and comparison:

Sounds like it's basically explained in the gh-ost readme https://github.com/github/gh-ost#how

I think it amounts to "use views to decouple access to the table with a fixed interface" and "use triggers for migrating data between tables"

Gh-ost is the new hotness. Simple to use and lots of great features: https://github.com/github/gh-ost

As they have said it depends on the size of the table on disk and the number of rows, but an alter in production is not difficult to last from seconds to days. I don't know if you are doing the alter as is but try to check https://docs.percona.com/percona-toolkit/pt-online-schema-change.html or https://github.com/github/gh-ost , they usually simplify a lot the alters.

Not sure which version of MySQL you're using, but one approach would be to use a tool like pt-online-schema-change (from Percona) or g-host -- which will create a duplicate table and then swap it in place of the original table. It's a safer approach when operating in production environments. Here's a good comparison of the tools many people use https://planetscale.com/docs/learn/online-schema-change-tools-comparison

Actually I never tried but I was scared by the small print of GH not using RDS themselves [1] and Ghost relying on lower-level features that might be not easily available in RDS. Also I had the impression you have to setup a normal non-RDS replica attached to your RDS master?

[1] https://github.com/github/gh-ost/blob/master/doc/rds.md

MySQL has some robust tooling in this space. Some of the tools use triggers to copy to a new table. GitHub's gh-ost[1] is probably the state of the art, and uses the binary log stream to replicate the data.

[1] https://github.com/github/gh-ost

https://github.com/github/gh-ost/issues/331#issuecomment-266...) it does become a little bit of a "you do not have google problems" type discussion.

(Perhaps you do have such problems, I don't know where you work! But 99%+ of companies don't have such problems and never will.)

GitHub doesn't use foreign keys[1], and there's likely many tables related to all the users, notifications, permissions, etc... that would need to be cleaned up. Without foreign keys they likely have some system process that does this instead of a simple `DELETE FROM` which cascades.

1. https://github.com/github/gh-ost/issues/331#issuecomment-266...

Boy, I can't find this either (but also, the kernel mailing list is _really_ difficult to search). I really remember Linus saying something like "it's not a real SCM, but maybe someone could build one on top of it someday" or something like that, but I cannot figure out how to find that.

You _can_ see, though, that in his first README, he refers to what he's building as not a "real SCM":

https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...

Here is the direct link, as HN somehow removes the query string: https://github.com/git/git/commits?author=peff&since=2023-10...

Yes, but you are referring to standalone scripts, not functions defined within a Bash script.

Compare for example the following helper code used for git command completion inside Bash and inside PowerShell.

Bash: https://github.com/git/git/blob/master/contrib/completion/gi...

`master` is also used as the default name for the default branch in newly created repositories. See option `--initial-branch` of `git init` and config variable `init.defaultBranch` [2] to override. Git for Windows, for example, allows setting the config option in its installer.

Source code:

- for merge commit formatting: https://github.com/git/git/blob/2108fe4a1976f95821e13503fd33...

> which branch on a remote is considered the default

That part is actually covered by "the default branch in newly created repositories". There are two different places where its done:

- This is the one you probably mean: [1]

- This is an obscure feature: [2]. A Stack Overflow comment [3] calls it "one of the abandoned experiments that were being done before the concept of a remote was invented".

Both of the places use function git_default_branch_name from refs.c [4], which uses config variable `init.defaultBranch` I've mentioned above.

[1] https://github.com/git/git/blob/v2.43.0/remote.c#L2380-L2383

[2] https://github.com/git/git/blob/v2.43.0/remote.c#L328-L338

[3] https://stackoverflow.com/a/54132016/1083697

[4] https://github.com/git/git/blob/v2.43.0/refs.c#L671-L705

There's a comment about that here: https://github.com/git/git/blob/bc5204569f7db44d22477485afd5...

    When writing or updating patterns, assume that the contents these

You know another project with much of its source files in the top-level directory? https://github.com/git/git