-# 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.
+[](https://dev.azure.com/git/git/_build/latest?definitionId=11)
+
+Git - fast, scalable, distributed revision control system
+=========================================================
+
+Git is a fast, scalable, distributed revision control system with an
+unusually rich command set that provides both high-level operations
+and full access to internals.
+
+Git is an Open Source project covered by the GNU General Public
+License version 2 (some parts of it are under different licenses,
+compatible with the GPLv2). It was originally written by Linus
+Torvalds with help of a group of hackers around the net.
+
+Please read the file [INSTALL][] for installation instructions.
+
+Many Git online resources are accessible from <https://git-scm.com/>
+including full documentation and Git related tools.
+
+See [Documentation/gittutorial.txt][] to get started, then see
+[Documentation/giteveryday.txt][] for a useful minimum set of commands, and
+`Documentation/git-<commandname>.txt` for documentation of each command.
+If git has been correctly installed, then the tutorial can also be
+read with `man gittutorial` or `git help tutorial`, and the
+documentation of each command with `man git-<commandname>` or `git help
+<commandname>`.
+
+CVS users may also want to read [Documentation/gitcvs-migration.txt][]
+(`man gitcvs-migration` or `git help cvs-migration` if git is
+installed).
+
+The user discussion and development of Git take place on the Git
+mailing list -- everyone is welcome to post bug reports, feature
+requests, comments and patches to git@vger.kernel.org (read
+[Documentation/SubmittingPatches][] for instructions on patch submission).
+To subscribe to the list, send an email with just "subscribe git" in
+the body to majordomo@vger.kernel.org. The mailing list archives are
+available at <https://public-inbox.org/git/>,
+<http://marc.info/?l=git> and other archival sites.
+
+Issues which are security relevant should be disclosed privately to
+the Git Security mailing list <git-security@googlegroups.com>.
+
+The maintainer frequently sends the "What's cooking" reports that
+list the current status of various development topics to the mailing
+list. The discussion following them give a good reference for
+project status, development direction and remaining tasks.
+
+The name "git" was given by Linus Torvalds when he wrote the very
+first version. He described the tool as "the stupid content tracker"
+and the name as (depending on your mood):
+
+ - random three-letter combination that is pronounceable, and not
+ actually used by any common UNIX command. The fact that it is a
+ mispronunciation of "get" may or may not be relevant.
+ - stupid. contemptible and despicable. simple. Take your pick from the
+ dictionary of slang.
+ - "global information tracker": you're in a good mood, and it actually
+ works for you. Angels sing, and a light suddenly fills the room.
+ - "goddamn idiotic truckload of sh*t": when it breaks
+
+[INSTALL]: INSTALL
+[Documentation/gittutorial.txt]: Documentation/gittutorial.txt
+[Documentation/giteveryday.txt]: Documentation/giteveryday.txt
+[Documentation/gitcvs-migration.txt]: Documentation/gitcvs-migration.txt
+[Documentation/SubmittingPatches]: Documentation/SubmittingPatches
projects / thirdparty / git.git / blobdiff