From 0539b9f54d4dfe6724a8adf1b1bd45a0cbb58b07 Mon Sep 17 00:00:00 2001 From: Julia Evans Date: Mon, 27 Oct 2025 16:31:43 -0400 Subject: [PATCH 1/3] about: Remove outdated About pages and rewrite About These pages are trying to convince the reader that Git is better than Subversion, which isn't the relevant thing to communicate to people learning about Git today. Write a single short About page, and make the rest of the About pages redirect to /about Also: - remove special "About" template - remove tests for "small-and-fast" Signed-off-by: Julia Evans --- content/about/_index.html | 76 +++++- content/about/branching-and-merging.html | 61 ----- content/about/data-assurance.html | 36 --- content/about/distributed.html | 130 ----------- content/about/free-and-open-source.html | 28 --- content/about/small-and-fast.html | 279 ----------------------- content/about/staging-area.html | 35 --- content/about/trademark.html | 12 +- layouts/_default/baseof.html | 14 -- tests/git-scm.spec.js | 12 - 10 files changed, 77 insertions(+), 606 deletions(-) delete mode 100644 content/about/branching-and-merging.html delete mode 100644 content/about/data-assurance.html delete mode 100644 content/about/distributed.html delete mode 100644 content/about/free-and-open-source.html delete mode 100644 content/about/small-and-fast.html delete mode 100644 content/about/staging-area.html diff --git a/content/about/_index.html b/content/about/_index.html index 92c652769b..b56454c4de 100644 --- a/content/about/_index.html +++ b/content/about/_index.html @@ -1,6 +1,80 @@ --- -redirect_to: about/branching-and-merging url: /about.html +section: "about" aliases: - /about/index.html +- /about/branching-and-merging.html +- /about/branching-and-merging/index.html +- /about/data-assurance.html +- /about/data-assurance/index.html +- /about/distributed.html +- /about/distributed/index.html +- /about/free-and-open-source.html +- /about/free-and-open-source/index.html +- /about/small-and-fast.html +- /about/small-and-fast/index.html +- /about/staging-area.html +- /about/staging-area/index.html --- + +
+

About Git

+ +

Git is fast

+ +

+Git was built to work on the Linux kernel, meaning that it was built to handle +repositories with tens of millions of lines of code from the start. +Speed and performance has always been a primary design goal of Git. +

+ +

+Git also stores repository history efficiently. As of 2025, the current version +of the Linux kernel's source code is 1.7 GB. +Git stores the full history of the Linux project (1.4 million commits) in only 5.5 GB. +

+ +

Git is widely used

+ +

+According to the 2022 Stack Overflow developer survey, +96% of professional developers use Git. +

+ +

Git has a huge ecosystem of tools

+ +

+The core Git project is just a command-line tool, but Git exploded in popularity +in the early 2010s thanks to }}">Git hosting services +like GitLab, GitHub, and more. +

+ +

+Since Git was created, many +}}">GUIs, editor integrations, +and +}}">command line tools +have been built to make working with Git more convenient. +You favorite developer tools might already have a built-in Git integration. +

+ +

Free and Open Source

+ +

+ Git is released under the + GNU General Public License version 2.0, which is an + open source license. + The Git project chose to use GPLv2 to guarantee your freedom to + share and change free software---to make sure the software is + free for all its users. +

+ +

+ However, we do restrict the use of the term "Git" and the + }}">logos to avoid confusion. Please see our + }}">trademark policy for details. +

+ + +
+ diff --git a/content/about/branching-and-merging.html b/content/about/branching-and-merging.html deleted file mode 100644 index 6cd3e0c8db..0000000000 --- a/content/about/branching-and-merging.html +++ /dev/null @@ -1,61 +0,0 @@ ---- -order: 1 -section: "about" -subsection: "branching-and-merging" -subtitle: "Branching and Merging" -display_class: "three-line" -url: /about/branching-and-merging.html -aliases: - - /about/branching-and-merging/index.html - - /about.html - - /about/index.html ---- -
- -

Branching and Merging

- -

- The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model. -

- -

- Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds. -

- -

- This means that you can do things like: -

- -
    -
  • - Frictionless Context Switching. Create a branch to try out an idea, commit a few times, switch back to where you branched from, apply a patch, switch back to where you are experimenting, and merge it in. -
  • -
  • - Role-Based Codelines. Have a branch that always contains only what goes to production, another that you merge work into for testing, and several smaller ones for day to day work. -
  • -
  • - Feature Based Workflow. Create new branches for each new feature you're working on so you can seamlessly switch back and forth between them, then delete each branch when that feature gets merged into your main line. -
  • -
  • - Disposable Experimentation. Create a branch to experiment in, realize it's not going to work, and just delete it - abandoning the work—with nobody else ever seeing it (even if you've pushed other branches in the meantime). -
  • -
- -

- }}" width="500" height="288" alt="Branches"> -

- -

- Notably, when you push to a remote repository, you do not have to push all of your branches. You can choose to share just one of your branches, a few of them, or all of them. This tends to free people to try new ideas without worrying about having to plan how and when they are going to merge it in or share it with others. -

- -

- There are ways to accomplish some of this with other systems, but the work involved is much more difficult and error-prone. Git makes this process incredibly easy and it changes the way most developers work when they learn it. -

- - - -
- diff --git a/content/about/data-assurance.html b/content/about/data-assurance.html deleted file mode 100644 index 06b9daff6f..0000000000 --- a/content/about/data-assurance.html +++ /dev/null @@ -1,36 +0,0 @@ ---- -order: 4 -section: "about" -subsection: "data-assurance" -subtitle: "Data Assurance" -display_class: "two-line" -aliases: - - /about/data-assurance/index.html - - /about/info-assurance.html - - /about/info-assurance/index.html ---- -
-

Data Assurance

-

- The data model that Git uses ensures the cryptographic integrity of every bit - of your project. Every file and commit is checksummed and retrieved by its - checksum when checked back out. It's impossible to get anything out of Git - other than the exact bits you put in. -

- }}" width="628"> -

- It is also impossible to change any file, date, commit message, or any other - data in a Git repository without changing the IDs of everything after it. - This means that if you have a commit ID, you can be assured not only that - your project is exactly the same as when it was committed, but - that nothing in its history was changed. -

-

- Most centralized version control systems provide no such integrity by default. -

- -
- diff --git a/content/about/distributed.html b/content/about/distributed.html deleted file mode 100644 index e17e8700ae..0000000000 --- a/content/about/distributed.html +++ /dev/null @@ -1,130 +0,0 @@ ---- -order: 3 -section: "about" -subsection: "distributed" -subtitle: "Distributed" -display_class: "one-line" -aliases: -- /about/distributed/index.html ---- -
- -

Distributed

- -

- One of the nicest features of any Distributed SCM, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository. -

-

Multiple Backups

-

- This means that even if you're using a centralized workflow, every user essentially has a full backup of the main server. Each of these copies could be pushed up to replace the main server in the event of a crash or corruption. In effect, there is no single point of failure with Git unless there is only a single copy of the repository. -

-

Any Workflow

-

- Because of Git's distributed nature and superb branching system, an almost endless number of workflows can be implemented with relative ease. -

-

Subversion-Style Workflow

-

- A centralized workflow is very common, especially from people transitioning from a centralized system. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine. -

-

- {{< graphviz alt="workflow A" >}} - digraph dev_workflow { - layout=neato; - overlap=false; - sep="+10"; - node [shape=box, style="filled,rounded", penwidth=0, fontname="Helvetica"]; - edge [penwidth=3, color="gray", arrowsize=0.5, dir=both]; - - shared_repo [label="shared repository", fillcolor=teal, fontcolor=white, pos="2,1.5!"]; - - developer1 [label="developer", fillcolor=lightblue, pos="0,0!"]; - developer2 [label="developer", fillcolor=lightblue, pos="2,0!"]; - developer3 [label="developer", fillcolor=lightblue, pos="4,0!"]; - - developer1 -> shared_repo; - developer2 -> shared_repo; - developer3 -> shared_repo; - } - {{< /graphviz >}} -

-

Integration Manager Workflow

-

- Another common Git workflow involves an integration manager — a single person who commits to the 'blessed' repository. A number of developers then clone from that repository, push to their own independent repositories, and ask the integrator to pull in their changes. This is the type of development model often seen with open source or GitHub repositories. -

-

- {{< graphviz alt="workflow B" >}} - digraph workflow { - layout=neato; - overlap=false; - node [shape=box, style="filled,rounded", penwidth=0, fontname="Helvetica"]; - edge [penwidth=3, color="gray", arrowsize=0.5]; - - // Nodes - blessed_repo [label="blessed\nrepository", fillcolor=teal, fontcolor=white, margin="0.3", pos="0,3!"]; - integration_manager [label="integration\nmanager", fillcolor=orange, fontcolor=white, pos="0,1!"]; - - dev_pub1 [label="developer\npublic", fillcolor="#CCAA00", fontcolor=black, pos="2,3!"]; - dev_pub2 [label="developer\npublic", fillcolor="#CCAA00", fontcolor=black, pos="4,3!"]; - - dev_priv1 [label="developer\nprivate", fillcolor="#CCAA00", fontcolor=black, pos="2,1!"]; - dev_priv2 [label="developer\nprivate", fillcolor="#CCAA00", fontcolor=black, pos="4,1!"]; - - // Edges with labels - dev_priv1 -> dev_pub1; - dev_priv2 -> dev_pub2; - integration_manager -> blessed_repo; - - dev_pub1 -> integration_manager [color="lightgray"]; - dev_pub2 -> integration_manager [color="lightgray"]; - blessed_repo -> dev_priv1 [color="lightgray"]; - blessed_repo -> dev_priv2 [color="lightgray"]; - } - {{< /graphviz >}} -

-

Dictator and Lieutenants Workflow

-

- For more massive projects, a development workflow like that of the Linux kernel is often effective. - In this model, some people ('lieutenants') are in charge of a specific subsystem of the project and they merge in all changes related to that subsystem. Another integrator (the 'dictator') can pull changes from only his/her lieutenants and then push to the 'blessed' repository that everyone then clones from again. -

-

- {{< graphviz alt="workflow C" >}} - digraph workflow { - layout=neato; - overlap=false; - node [shape=box, style="filled,rounded", penwidth=0, fontname="Helvetica"]; - edge [penwidth=3, color="gray", arrowsize=0.5]; - - // Nodes - blessed_repo [label="blessed\nrepository", fillcolor=teal, fontcolor=white, margin="0.3", pos="6,4!"]; - dictator [label="dictator", fillcolor=red, fontcolor=white, pos="0,4!"]; - - lieutenant1 [label="lieutenant", fillcolor="#CCAA00", fontcolor=white, pos="0,2.5!"]; - lieutenant2 [label="lieutenant", fillcolor="#CCAA00", fontcolor=white, pos="2,3!"]; - - developer1 [label="developer", fillcolor=lightblue, fontcolor=black, pos="0,1!"]; - developer2 [label="developer", fillcolor=lightblue, fontcolor=black, pos="2,1!"]; - developer3 [label="developer", fillcolor=lightblue, fontcolor=black, pos="4,1!"]; - developer4 [label="developer", fillcolor=lightblue, fontcolor=black, pos="6,1!"]; - - // Edges - dictator -> blessed_repo; - lieutenant1 -> dictator; - lieutenant2 -> dictator; - - developer1 -> lieutenant1; - developer2 -> lieutenant1; - developer3 -> lieutenant2; - developer4 -> lieutenant2; - - blessed_repo -> developer1; - blessed_repo -> developer2; - blessed_repo -> developer3; - blessed_repo -> developer4; - } - {{< /graphviz >}} -

- -
diff --git a/content/about/free-and-open-source.html b/content/about/free-and-open-source.html deleted file mode 100644 index a9037ab47c..0000000000 --- a/content/about/free-and-open-source.html +++ /dev/null @@ -1,28 +0,0 @@ ---- -order: 6 -section: "about" -subsection: "free-and-open-source" -subtitle: "Free and Open Source" -display_class: "three-line" -aliases: -- /about/free-and-open-source/index.html ---- -
-

Free and Open Source

-

Git is released under the GNU General Public License version 2.0, which is an - open source license. - The Git project chose to use GPLv2 to guarantee your freedom to - share and change free software---to make sure the software is - free for all its users.

- -

However, we do restrict the use of the term "Git" and the - }}">logos to avoid confusion. Please - see our }}">trademark policy for - details.

- - -
diff --git a/content/about/small-and-fast.html b/content/about/small-and-fast.html deleted file mode 100644 index 05057ffb70..0000000000 --- a/content/about/small-and-fast.html +++ /dev/null @@ -1,279 +0,0 @@ ---- -order: 2 -section: "about" -subsection: "small-and-fast" -subtitle: "Small and Fast" -display_class: "two-line" -aliases: -- /about/small-and-fast/index.html ---- -
- -

Small and Fast

- -

- Git is fast. With Git, nearly all operations are performed locally, giving it a huge speed advantage on centralized systems that constantly have to communicate with a server somewhere. -

- -

- Git was built to work on the Linux kernel, meaning that it has had to effectively handle large repositories from day one. Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Speed and performance has been a primary design goal of Git from the start. -

- -

Benchmarks

- -

- Let's see how common operations stack up against - Subversion, a common centralized version control system that is similar - to CVS or Perforce. Smaller is faster. -

- -
-
-
-
Commit A
-
- - git -
-
- - svn -
-
-
-
-
-
Commit B
-
- - git -
-
- - svn -
-
-
-
-
-
Diff Curr
-
- - git -
-
- - svn -
-
-
-
-
-
Diff Rec
-
- - git -
-
- - svn -
-
-
-
-
-
Diff Tags
-
- - git -
-
- - svn -
-
-
-
-
-
Clone
-
- - git* -
-
- - git -
-
- -
-
-
-
-
-
Log (50)
-
- - git -
-
- - svn -
-
-
-
-
-
Log (All)
-
- - git -
-
- - svn -
-
-
-
-
-
Log (File)
-
- - git -
-
- - svn -
-
-
-
-
-
Update
-
- - git -
-
- - svn -
-
-
-
-
-
Blame
-
- - git -
-
- - svn -
-
-
-
-
-
Size
-
- - git -
-
- - svn -
-
-
-
- -

- For testing, large AWS instances were set up in the same availability zone. - Git and SVN were installed on both machines, the Ruby repository was copied to - both Git and SVN servers, and common operations were performed on both. -

- -

- In some cases, the commands don't match up exactly. Here, matching on the lowest - common denominator was attempted. For example, the 'commit' tests also include - the time to push for Git, though most of the time you would not actually be pushing - to the server immediately after a commit where the two commands cannot be separated - in SVN. -

- -

- All of these times are in seconds. -

-
- - - - - - - - - - - - - - - - - - - -
OperationGitSVN
Commit Files (A)Add, commit and push 113 modified files (2164+, 2259-)0.642.604x
Commit Images (B)Add, commit and push a thousand 1 kB images1.5324.7016x
Diff CurrentDiff 187 changed files (1664+, 4859-) against last commit0.251.094x
Diff RecentDiff against 4 commits back (269 changed/3609+,6898-)0.253.9916x
Diff TagsDiff two tags against each other (v1.9.1.0/v1.9.3.0)1.1783.5771x
Log (50)Log of the last 50 commits (19 kB of output)0.010.3831x
Log (All)Log of all commits (26,056 commits – 9.4 MB of output)0.52169.20325x
Log (File)Log of the history of a single file (array.c – 483 revs)0.6082.84138x
UpdatePull of Commit A scenario (113 files changed, 2164+, 2259-)0.902.823x
BlameLine annotation of a single file (array.c)1.913.041x
-
-

- Note that this is the best case scenario for SVN—a server with no load with a - gigabit connection to the client machine. Nearly all of these - times would be even worse for SVN if that connection was slower, while - many of the Git times would not be affected. -

- -

- Clearly, in many of these common version control operations, Git is - one or two orders of magnitude faster than SVN, even under ideal conditions - for SVN. -

- -

- One place where Git is slower is in the initial clone operation. - Here, Git is downloading the entire history rather than only the latest - version. As seen in the above charts, it's not considerably slower for an operation - that is only performed once. -

- -
- - - - - - - - - - - - -
OperationGit*GitSVN
CloneClone and shallow clone(*) in Git vs checkout in SVN21.0107.514.0
Size (MB)Size of total client side data and files after clone/checkout (in MB)181.0132.0
-
- -

- It's also interesting to note that the size of the data on the client side - is very similar even though Git also has every version of every file for the - entire history of the project. This illustrates how efficient it is at compressing - and storing data on the client side. -

- - - -
diff --git a/content/about/staging-area.html b/content/about/staging-area.html deleted file mode 100644 index 017908b6e1..0000000000 --- a/content/about/staging-area.html +++ /dev/null @@ -1,35 +0,0 @@ ---- -order: 5 -section: "about" -subsection: "staging-area" -subtitle: "Staging Area" -display_class: "two-line" -aliases: -- /about/staging-area/index.html ---- -
-

Staging Area

-

- Unlike the other systems, Git has something called the "staging area" or "index". This is an intermediate area where commits can be formatted and reviewed before completing the commit. -

-

- One thing that sets Git apart from other tools is that it's possible to quickly stage some of your files and commit them without committing all of the other modified files in your working directory or having to list them on the command line during the commit. -

-

- }}" width="336" height="194" alt="Index 1"> -

-

- This allows you to stage only portions of a modified file. Gone are the days of making two logically unrelated modifications to a file before you realized that you forgot to commit one of them. Now you can just stage the change you need for the current commit and stage the other change for the next commit. This feature scales up to as many different changes to your file as needed. -

-

- Of course, Git also makes it easy to ignore this feature if you don't want that kind of control — just add a '-a' to your commit command in order to add all changes to all files to the staging area. -

-

- }}" width="338" height="185" alt="Index 2"> -

- -
- diff --git a/content/about/trademark.html b/content/about/trademark.html index 30c807ee1f..e8437d1a8a 100644 --- a/content/about/trademark.html +++ b/content/about/trademark.html @@ -1,15 +1,12 @@ --- -order: 7 section: "about" subsection: "trademark" -subtitle: "Trademark" -display_class: "one-line" aliases: - /trademark.html - /trademark/index.html - /about/trademark/index.html --- -
+

GIT TRADEMARK POLICY

@@ -188,9 +185,4 @@

4 Questions

TRADEMARK@SFCONSERVANCY.ORG or by writing to Git Project c/o Software Freedom Conservancy, 137 Montague St. Ste 380, Brooklyn, NY 11201-3548.

- - - -
+ diff --git a/layouts/_default/baseof.html b/layouts/_default/baseof.html index 0dec379d84..a7ecddf54d 100644 --- a/layouts/_default/baseof.html +++ b/layouts/_default/baseof.html @@ -177,20 +177,6 @@

{{ .Params.video_title }}

- {{ else if eq $section "about" }} -
-

About{{ if (isset .Params "subtitle") }} - {{ .Params.subtitle }}{{ end }}

- -
    - {{ $abouts := sort (where .Site.RegularPages "Params.section" "about") "Params.order" }} - {{ range $about := $abouts }} -
  1. - {{ $about.Params.subtitle }} -
  2. - {{ end }} -
- {{ .Content }} -
{{ else }} {{ .Content }} {{ end }} diff --git a/tests/git-scm.spec.js b/tests/git-scm.spec.js index b8de0ebf2a..0a748f3870 100644 --- a/tests/git-scm.spec.js +++ b/tests/git-scm.spec.js @@ -303,18 +303,6 @@ test('sidebar', async ({ page }) => { await expect(page.getByRole('heading', { name: 'About - Branching and Merging' })).toBeVisible(); }); -test('small-and-fast', async ({ page }) => { - await page.setViewportSize(devices['iPhone X'].viewport); - - await page.goto(`${url}about/small-and-fast`); - - // Scroll to text right below the graphs - await page.getByText('For testing, large AWS instances').scrollIntoViewIfNeeded(); - - const lastGraph = page.locator('.bar-chart').last(); - await expect(lastGraph).toBeInViewport(); -}); - test('dark mode', async({ page }) => { // Helper: returns relative luminance in range [0, 1] const getPageBrightness = async () => { From 305f215f6b8043133f9cedb733366dcc72e33781 Mon Sep 17 00:00:00 2001 From: Julia Evans Date: Tue, 28 Oct 2025 15:23:04 -0400 Subject: [PATCH 2/3] about: update homepage and sidebar Update the copy on the homepage to reflect the new content of the About page, and remove the now-deleted about pages from the sidebar. Signed-off-by: Julia Evans --- layouts/partials/masthead.html | 12 +++++------- layouts/partials/sidebar.html | 14 ++++---------- layouts/partials/site-root.html | 2 +- 3 files changed, 10 insertions(+), 18 deletions(-) diff --git a/layouts/partials/masthead.html b/layouts/partials/masthead.html index 77075c9ab7..bb7a017c31 100644 --- a/layouts/partials/masthead.html +++ b/layouts/partials/masthead.html @@ -2,17 +2,15 @@

- Git is a free and open source + Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

- Git is easy to learn and has a - tiny footprint with lightning fast performance. - It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase - with features like cheap local branching, - convenient staging areas, and - multiple workflows. + Git is lightning fast and has a huge ecosystem of + GUIs, + hosting services, and + command-line tools.

diff --git a/layouts/partials/sidebar.html b/layouts/partials/sidebar.html index 512839a656..a73d6a4b8e 100644 --- a/layouts/partials/sidebar.html +++ b/layouts/partials/sidebar.html @@ -5,16 +5,10 @@
  • About - - {{ if (eq $section "about") }} - {{ $subsection := .Params.subsection }} - {{ $abouts := sort (where .Site.RegularPages "Params.section" "about") "Params.order" }} - {{ range $i, $about := $abouts }} -
  • - {{ $about.Params.subtitle }} -
  • - {{ end }} - {{ end }} + diff --git a/layouts/partials/site-root.html b/layouts/partials/site-root.html index a6390cd241..8362e0e1e0 100644 --- a/layouts/partials/site-root.html +++ b/layouts/partials/site-root.html @@ -6,7 +6,7 @@

    About

    -

    The advantages of Git compared to other source control systems.

    +

    Git's performance and ecosystem

  • From 635d99ef4bcba8ca4253443c1cb8d8c572f44ae8 Mon Sep 17 00:00:00 2001 From: Julia Evans Date: Tue, 28 Oct 2025 15:41:18 -0400 Subject: [PATCH 3/3] about: remove #about-nav CSS Signed-off-by: Julia Evans --- assets/sass/dark-mode.scss | 4 -- assets/sass/lists.scss | 76 -------------------------------------- 2 files changed, 80 deletions(-) diff --git a/assets/sass/dark-mode.scss b/assets/sass/dark-mode.scss index b6d32ae43b..3997a0a193 100644 --- a/assets/sass/dark-mode.scss +++ b/assets/sass/dark-mode.scss @@ -92,10 +92,6 @@ img:not(.no-filter) { filter: brightness(0.9) contrast(0.6) invert(1); } - - ol#about-nav li a { - filter: brightness(0.8); - } } img[alt="Git"] { diff --git a/assets/sass/lists.scss b/assets/sass/lists.scss index 5a028bc59e..9e766fc81d 100644 --- a/assets/sass/lists.scss +++ b/assets/sass/lists.scss @@ -72,62 +72,6 @@ ul.books-list { } } -ol#about-nav { - @extend .unstyled !optional; - @include clearfix; - - li { - display: inline; - float: left; - width: 80px; - height: 85px; - padding-right: 5px; - margin-right: 7px; - - &:last-child { - margin-right: 0; - } - - a { - display: block; - width: 60px; - height: 80px; - padding: 0 15px; - font-size: 13px; - line-height: 20px; - text-align: center; - color: var(--light-font-color-darker-35); - opacity: 0.9; - @include background-image-2x($baseurl + "images/icons/nav-circles", 90px, 180px); - - &.current { - @include background-image-2x($baseurl + "images/icons/nav-circles", 90px, 180px, 0 -90px); - color: var(--main-bg); - opacity: 1; - } - - &.one-line { - height: 55px; - padding-top: 35px; - } - - &.two-line { - height: 62px; - padding-top: 28px; - } - - &.three-line { - height: 73px; - padding-top: 17px; - } - - &:hover { - opacity: 1; - } - } - } -} - ul.stackoverflow { @extend .unstyled !optional; font-size: 12px; @@ -168,23 +112,3 @@ table.binaries { border: solid 1px transparent; } } -// Breakpoint ---- -@media (max-width: $default){ - ol#about-nav { - display: flex; - flex-wrap: wrap; - justify-content: space-between; - } -} - -@media (max-width: $mobile-m){ - ol#about-nav { - justify-content: unset; - li { - padding-right: 0; - margin-right: 0.6rem; - flex-basis: 29%; - margin-bottom: 1rem; - } - } -}