revert(3p/git): Revert merge of git upstream at v2.26.2 r/852

This causes cgit to serve error pages, which is undesirable.

This reverts commit 5229c9b232de5bfa959ad6ebbb4c8192ac513352, reversing
changes made to f2b211131f2347342dde63975b09cf603149f1a3.

1 files changed, 0 insertions, 174 deletions

diff --git a/third_party/git/git-gui/README.md b/third_party/git/git-gui/README.md
deleted file mode 100644
index 5ce2122fbc61..000000000000
--- a/third_party/git/git-gui/README.md
+++ /dev/null
@@ -1,174 +0,0 @@
-# Git GUI - A graphical user interface for Git
-
-Git GUI allows you to use the [Git source control management
-tools](https://git-scm.com/) via a GUI. This includes staging, committing,
-adding, pushing, etc. It can also be used as a blame viewer, a tree browser,
-and a citool (make exactly one commit before exiting and returning to shell).
-More details about Git GUI can be found in its manual page by either running
-`man git-gui`, or by visiting the [online manual
-page](https://git-scm.com/docs/git-gui).
-
-Git GUI was initially written by Shawn O. Pearce, and is distributed with the
-standard Git installation.
-
-# Building and installing
-
-You need to have the following dependencies installed before you begin:
-
-- Git
-- Tcl
-- Tk
-- wish
-- Gitk (needed for browsing history)
-- msgfmt
-
-Most of Git GUI is written in Tcl, so there is no compilation involved. Still,
-some things do need to be done (mostly some substitutions), so you do need to
-"build" it.
-
-You can build Git GUI using:
-
-```
-make
-```
-
-And then install it using:
-
-```
-make install
-```
-
-You probably need to have root/admin permissions to install.
-
-# Contributing
-
-The project is currently maintained by Pratyush Yadav over at
-https://github.com/prati0100/git-gui. Even though the project is hosted at
-GitHub, the development does not happen over GitHub Issues and Pull Requests.
-Instead, an email based workflow is used. The Git mailing list
-[git@vger.kernel.org](mailto:git@vger.kernel.org) is where the patches are
-discussed and reviewed.
-
-More information about the Git mailing list and instructions to subscribe can
-be found [here](https://git.wiki.kernel.org/index.php/GitCommunity).
-
-## Sending your changes
-
-Since the development happens over email, you need to send in your commits in
-text format. Commits can be converted to emails via the two tools provided by
-Git: `git-send-email` and `git-format-patch`.
-
-You can use `git-format-patch` to generate patches in mbox format from your
-commits that can then be sent via email. Let's say you are working on a branch
-called 'foo' that was created on top of 'master'. You can run:
-
-```
-git format-patch -o output_dir master..foo
-```
-
-to convert all the extra commits in 'foo' into a set of patches saved in the
-folder `output_dir`.
-
-If you are sending multiple patches, it is recommended to include a cover
-letter. A cover letter is an email explaining in brief what the series is
-supposed to do. A cover letter template can be generated by passing
-`--cover-letter` to `git-format-patch`.
-
-After you send your patches, you might get a review suggesting some changes.
-Make those changes, and re-send your patch(es) in reply to the first patch of
-your initial version. Also please mention the version of the patch. This can be
-done by passing `-v X` to `git-format-patch`, where 'X' is the version number
-of the patch(es).
-
-### Using git-send-email
-
-You can use `git-send-email` to send patches generated via `git-format-patch`.
-While you can directly send patches via `git-send-email`, it is recommended
-that you first use `git-format-patch` to generate the emails, audit them, and
-then send them via `git-send-email`.
-
-A pretty good guide to configuring and using `git-send-email` can be found
-[here](https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/)
-
-### Using your email client
-
-If your email client supports sending mbox format emails, you can use
-`git-format-patch` to get an mbox file for each commit, and then send them. If
-there is more than one patch in the series, then all patches after the first
-patch (or the cover letter) need to be sent as replies to the first.
-`git-send-email` does this by default.
-
-### Using GitGitGadget
-
-Since some people prefer a GitHub pull request based workflow, they can use
-[GitGitGadget](https://gitgitgadget.github.io/) to send in patches. The tool
-was originally written for sending patches to the Git project, but it now also
-supports sending patches for git-gui.
-
-Instructions for using GitGitGadget to send git-gui patches, courtesy of
-Johannes Schindelin:
-
-If you don't already have a fork of the [git/git](https://github.com/git/git)
-repo, you need to make one. Then clone your fork:
-
-```
-git clone https://github.com/<your-username>/git
-```
-
-Then add GitGitGadget as a remote:
-
-```
-git remote add gitgitgadget https://github.com/gitgitgadget/git
-```
-
-Then fetch the git-gui branch:
-
-```
-git fetch gitgitgadget git-gui/master
-```
-
-Then create a new branch based on git-gui/master:
-
-```
-git checkout -b <your-branch-name> git-gui/master
-```
-
-Make whatever commits you need to, push them to your fork, and then head over
-to https://github.com/gitgitgadget/git/pulls and open a Pull Request targeting
-git-gui/master.
-
-GitGitGadget will welcome you with a (hopefully) helpful message.
-
-## Signing off
-
-You need to sign off your commits before sending them to the list. You can do
-that by passing the `-s` option to `git-commit`. You can also use the "Sign
-Off" option in Git GUI.
-
-A sign-off is a simple 'Signed-off-by: A U Thor \<author@example.com\>' line at
-the end of the commit message, after your explanation of the commit.
-
-A sign-off means that you are legally allowed to send the code, and it serves
-as a certificate of origin. More information can be found at
-[developercertificate.org](https://developercertificate.org/).
-
-## Responding to review comments
-
-It is quite likely your patches will get review comments. Those comments are
-sent on the Git mailing list as replies to your patch, and you will usually be
-Cc'ed in those replies.
-
-You are expected to respond by either explaining your code further to convince
-the reviewer what you are doing is correct, or acknowledge the comments and
-re-send the patches with those comments addressed.
-
-Some tips for those not familiar with communication on a mailing list:
-
-- Use only plain text emails. No HTML at all.
-- Wrap lines at around 75 characters.
-- Do not send attachments. If you do need to send some files, consider using a
-  hosting service, and paste the link in your email.
-- Do not [top post](http://www.idallen.com/topposting.html).
-- Always "reply all". Keep all correspondents and the list in Cc. If you reply
-  directly to a reviewer, and not Cc the list, other people would not be able
-  to chime in.