diff options
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 248 |
1 files changed, 74 insertions, 174 deletions
@@ -1,174 +1,74 @@ -# 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 Johannes Sixt at -https://github.com/j6t/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://github.com/git/git/actions?query=branch%3Amaster+event%3Apush) + +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.adoc][] to get started, then see +[Documentation/giteveryday.adoc][] for a useful minimum set of commands, and +`Documentation/git-<commandname>.adoc` 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.adoc][] +(`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 +and [Documentation/CodingGuidelines][]). + +Those wishing to help with error message, usage and informational message +string translations (localization l10) should see [po/README.md][] +(a `po` file is a Portable Object file that holds the translations). + +To subscribe to the list, send an email to <git+subscribe@vger.kernel.org> +(see https://subspace.kernel.org/subscribing.html for details). The mailing +list archives are available at <https://lore.kernel.org/git/>, +<https://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.adoc]: Documentation/gittutorial.adoc +[Documentation/giteveryday.adoc]: Documentation/giteveryday.adoc +[Documentation/gitcvs-migration.adoc]: Documentation/gitcvs-migration.adoc +[Documentation/SubmittingPatches]: Documentation/SubmittingPatches +[Documentation/CodingGuidelines]: Documentation/CodingGuidelines +[po/README.md]: po/README.md |