-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Git User's Manual (for version 1.5.3 or newer)</title><link rel="stylesheet" href="docbook-xsl.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.69.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id189136"></a>Git User's Manual (for version 1.5.3 or newer)</h1></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id264725">Preface</a></span></dt><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><
/dl></dd><dt><span class="section"><a href="#Finding-comments-with-given-content">Finding commits referencing a file with given content</a></span></dt></dl></dd><dt><span class="chapter"><a href="#Developing-with-git">3. Developing with git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-editing-history">Fixing a mistake by editing history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git-rebase</a></span></dt><dt><span class="section"><a href="#modifying-one-commit">Modifying a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-with-rewriting-history">Problems with rewriting history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-internals">7. Git internals</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#the-index">The "index" aka "Current Directory Cache"</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory -> index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index -> object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database -> index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index -> working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt><dt><span class="section"><a href="#pack-files">How git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">8. GIT Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></div><div class="preface" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id264725"></a>Preface</h2></div></div></div><p>Git is a fast distributed revision control system.</p><p>This manual is designed to be readable by someone with basic UNIX
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Git User's Manual (for version 1.5.3 or newer)</title><link rel="stylesheet" href="docbook-xsl.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.69.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id189136"></a>Git User's Manual (for version 1.5.3 or newer)</h1></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id264725">Preface</a></span></dt><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><
dt><span class="section"><a href="#Finding-comments-with-given-content">Finding commits referencing a file with given content</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#Developing-with-git">3. Developing with git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-editing-history">Fixing a mistake by editing history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git-rebase</a></span></dt><dt><span class="section"><a href="#modifying-one-commit">Modifying a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-with-rewriting-history">Problems with rewriting history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-internals">7. Git internals</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#the-index">The "index" aka "Current Directory Cache"</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory -> index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index -> object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database -> index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index -> working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt><dt><span class="section"><a href="#pack-files">How git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">8. GIT Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></div><div class="preface" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id264725"></a>Preface</h2></div></div></div><p>Git is a fast distributed revision control system.</p><p>This manual is designed to be readable by someone with basic UNIX
command-line skills, but no previous knowledge of git.</p><p><a href="#repositories-and-branches" title="Chapter 1. Repositories and Branches">Chapter 1, <i>Repositories and Branches</i></a> and <a href="#exploring-git-history" title="Chapter 2. Exploring git history">Chapter 2, <i>Exploring git history</i></a> explain how
to fetch and study a project using git—read these chapters to learn how
to build and test a particular version of a software project, search for
pages. For a command such as "git clone", just use</p><div class="literallayout"><p>$ man git-clone</p></div><p>See also <a href="#git-quick-start" title="Appendix A. Git Quick Reference">Appendix A, <i>Git Quick Reference</i></a> for a brief overview of git commands,
without any explanation.</p><p>Finally, see <a href="#todo" title="Appendix B. Notes and todo list for this manual">Appendix B, <i>Notes and todo list for this manual</i></a> for ways that you can help make this manual more
complete.</p></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="repositories-and-branches"></a>Chapter 1. Repositories and Branches</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="how-to-get-a-git-repository"></a>How to get a git repository</h2></div></div></div><p>It will be useful to have a git repository to experiment with as you
-read this manual.</p><p>The best way to get one is by using the <a href="git-clone.html" target="_top">git-clone(1)</a> command
-to download a copy of an existing repository for a project that you
-are interested in. If you don't already have a project in mind, here
-are some interesting examples:</p><div class="literallayout"><p> # git itself (approx. 10MB download):<br>
+read this manual.</p><p>The best way to get one is by using the <a href="git-clone.html" target="_top">git-clone(1)</a> command to
+download a copy of an existing repository. If you don't already have a
+project in mind, here are some interesting examples:</p><div class="literallayout"><p> # git itself (approx. 10MB download):<br>
$ git clone git://git.kernel.org/pub/scm/git/git.git<br>
# the linux kernel (approx. 150MB download):<br>
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git</p></div><p>The initial clone may be time-consuming for a large project, but you
("git" or "linux-2.6" in the examples above). After you cd into this
directory, you will see that it contains a copy of the project files,
together with a special top-level directory named ".git", which
-contains all the information about the history of the project.</p><p>In most of the following, examples will be taken from one of the two
-repositories above.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="how-to-check-out"></a>How to check out a different version of a project</h2></div></div></div><p>Git is best thought of as a tool for storing the history of a
-collection of files. It stores the history as a compressed
-collection of interrelated snapshots (versions) of the project's
-contents.</p><p>A single git repository may contain multiple branches. It keeps track
+contains all the information about the history of the project.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="how-to-check-out"></a>How to check out a different version of a project</h2></div></div></div><p>Git is best thought of as a tool for storing the history of a collection
+of files. It stores the history as a compressed collection of
+interrelated snapshots of the project's contents. In git each such
+version is called a <a href="#def_commit">commit</a>.</p><p>A single git repository may contain multiple branches. It keeps track
of them by keeping a list of <a href="#def_head">heads</a> which reference the
-latest
version on each branch; the <a href="git-branch.html" target="_top">git-branch(1)</a> command shows
+latest
commit on each branch; the <a href="git-branch.html" target="_top">git-branch(1)</a> command shows
you the list of branch heads:</p><div class="literallayout"><p>$ git branch<br>
* master</p></div><p>A freshly cloned repository contains a single branch head, by default
named "master", with the working directory initialized to the state of
carefully.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="understanding-commits"></a>Understanding History: Commits</h2></div></div></div><p>Every change in the history of a project is represented by a commit.
The <a href="git-show.html" target="_top">git-show(1)</a> command shows the most recent commit on the
current branch:</p><div class="literallayout"><p>$ git show<br>
-commit 2b5f6dcce5bf94b9b119e9ed8d537098ec61c3d2<br>
-Author: Jamal Hadi Salim <hadi@cyberus.ca><br>
-Date: Sat Dec 2 22:22:25 2006 -0800<br>
+commit 17cf781661e6d38f737f15f53ab552f1e95960d7<br>
+Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)><br>
+Date: Tue Apr 19 14:11:06 2005 -0700<br>
<br>
- [XFRM]: Fix aevent structuring to be more complete.<br>
+ Remove duplicate getenv(DB_ENVIRONMENT) call<br>
<br>
- aevents can not uniquely identify an SA. We break the ABI with this<br>
- patch, but consensus is that since it is not yet utilized by any<br>
- (known) application then it is fine (better do it now than later).<br>
+ Noted by Tony Luck.<br>
<br>
- Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca><br>
- Signed-off-by: David S. Miller <davem@davemloft.net><br>
+diff --git a/init-db.c b/init-db.c<br>
+index 65898fa..b002dc6 100644<br>
+--- a/init-db.c<br>
++++ b/init-db.c<br>
+@@ -7,7 +7,7 @@<br>
<br>
-diff --git a/Documentation/networking/xfrm_sync.txt b/Documentation/networking/xfrm_sync.txt<br>
-index 8be626f..d7aac9d 100644<br>
---- a/Documentation/networking/xfrm_sync.txt<br>
-+++ b/Documentation/networking/xfrm_sync.txt<br>
-@@ -47,10 +47,13 @@ aevent_id structure looks like:<br>
+ int main(int argc, char **argv)<br>
+ {<br>
+- char *sha1_dir = getenv(DB_ENVIRONMENT), *path;<br>
++ char *sha1_dir, *path;<br>
+ int len, i;<br>
<br>
- struct xfrm_aevent_id {<br>
- struct xfrm_usersa_id sa_id;<br>
-+ xfrm_address_t saddr;<br>
- __u32 flags;<br>
-+ __u32 reqid;<br>
- };<br>
-...</p></div><p>As you can see, a commit shows who made the latest change, what they
+ if (mkdir(".git", 0755) < 0) {</p></div><p>As you can see, a commit shows who made the latest change, what they
did, and why.</p><p>Every commit has a 40-hexdigit id, sometimes called the "object name" or the
"SHA1 id", shown on the first line of the "git show" output. You can usually
refer to a commit by a shorter name, such as a tag or a branch name, but this
...</p></div><p>This is what causes git to track the remote's branches; you may modify
or delete these configuration options by editing .git/config with a
text editor. (See the "CONFIGURATION FILE" section of
-<a href="git-config.html" target="_top">git-config(1)</a> for details.)</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="exploring-git-history"></a>Chapter 2. Exploring git history</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><
/dl></dd><dt><span class="section"><a href="#Finding-comments-with-given-content">Finding commits referencing a file with given content</a></span></dt></dl></div><p>Git is best thought of as a tool for storing the history of a
+<a href="git-config.html" target="_top">git-config(1)</a> for details.)</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="exploring-git-history"></a>Chapter 2. Exploring git history</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><
dt><span class="section"><a href="#Finding-comments-with-given-content">Finding commits referencing a file with given content</a></span></dt></dl></dd></dl></div><p>Git is best thought of as a tool for storing the history of a
collection of files. It does this by storing compressed snapshots of
the contents of a file hierarchy, together with "commits" which show
the relationships between these snapshots.</p><p>Git provides extremely flexible and fast tools for exploring the
echo "git log --no-merges v$new ^v$last > ../ChangeLog-$new"<br>
echo "git shortlog --no-merges v$new ^v$last > ../ShortLog"<br>
echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"</p></div><p>and then he just cut-and-pastes the output commands after verifying that
-they look OK.</p></div><
/div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Finding-comments-with-given-content"></a>Finding commits referencing a file with given content</h2></div></div></div><p>Somebody hands you a copy of a file, and asks which commits modified a
+they look OK.</p></div><
div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="Finding-comments-with-given-content"></a>Finding commits referencing a file with given content</h3></div></div></div><p>Somebody hands you a copy of a file, and asks which commits modified a
file such that it contained the given content either before or after the
commit. You can find out with this:</p><div class="literallayout"><p>$ git log --raw -r --abbrev=40 --pretty=oneline -- filename |<br>
grep -B 1 `git hash-object filename`</p></div><p>Figuring out why this works is left as an exercise to the (advanced)
student. The <a href="git-log.html" target="_top">git-log(1)</a>, <a href="git-diff-tree.html" target="_top">git-diff-tree(1)</a>, and
-<a href="git-hash-object.html" target="_top">git-hash-object(1)</a> man pages may prove helpful.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="Developing-with-git"></a>Chapter 3. Developing with git</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-editing-history">Fixing a mistake by editing history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="telling-git-your-name"></a>Telling git your name</h2></div></div></div><p>Before creating any commits, you should introduce yourself to git. The
+<a href="git-hash-object.html" target="_top">git-hash-object(1)</a> man pages may prove helpful.</p></div></div><
/div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="Developing-with-git"></a>Chapter 3. Developing with git</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-editing-history">Fixing a mistake by editing history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="telling-git-your-name"></a>Telling git your name</h2></div></div></div><p>Before creating any commits, you should introduce yourself to git. The
easiest way to do so is to make sure the following lines appear in a
file named .gitconfig in your home directory:</p><div class="literallayout"><p>[user]<br>
name = Your Name Comes Here<br>
is just a matter of <span class="emphasis"><em>not</em></span> calling "<code class="literal">git add</code>" on them. But it quickly becomes
annoying to have these untracked files lying around; e.g. they make
"<code class="literal">git add .</code>" and "<code class="literal">git commit -a</code>" practically useless, and they keep
-showing up in the output of "<code class="literal">git status</code>", etc.</p><p>Git therefore provides "exclude patterns" for telling git which files to
-actively ignore. Exclude patterns are thoroughly explained in the
-<a href="gitignore.html" target="_top">gitignore(5)</a> manual page, but the heart of the concept is simply
-a list of files which git should ignore. Entries in the list may contain
-globs to specify multiple files, or may be prefixed by "<code class="literal">!</code>" to
-explicitly include (un-ignore) a previously excluded (ignored) file
-(i.e. later exclude patterns override earlier ones). The following
-example should illustrate such patterns:</p><div class="literallayout"><p># Lines starting with '#' are considered comments.<br>
-# Ignore foo.txt.<br>
+showing up in the output of "<code class="literal">git status</code>".</p><p>You can tell git to ignore certain files by creating a file called .gitignore
+in the top level of your working directory, with contents such as:</p><div class="literallayout"><p># Lines starting with '#' are considered comments.<br>
+# Ignore any file named foo.txt.<br>
foo.txt<br>
# Ignore (generated) html files,<br>
*.html<br>
# except foo.html which is maintained by hand.<br>
!foo.html<br>
# Ignore objects and archives.<br>
-*.[oa]</p></div><p>The next question is where to put these exclude patterns so that git can
-find them. Git looks for exclude patterns in the following files:</p><div class="variablelist"><dl><dt><span class="term">
-<code class="literal">.gitignore</code> files in your working tree:
-</span></dt><dd>
- You may store multiple <code class="literal">.gitignore</code> files at various locations in your
- working tree. Each <code class="literal">.gitignore</code> file is applied to the directory where
- it's located, including its subdirectories. Furthermore, the
- <code class="literal">.gitignore</code> files can be tracked like any other files in your working
- tree; just do a "<code class="literal">git add .gitignore</code>" and commit. <code class="literal">.gitignore</code> is
- therefore the right place to put exclude patterns that are meant to
- be shared between all project participants, such as build output files
- (e.g. <code class="literal">*.o</code>), etc.
-</dd><dt><span class="term">
-<code class="literal">.git/info/exclude</code> in your repo:
-</span></dt><dd>
- Exclude patterns in this file are applied to the working tree as a
- whole. Since the file is not located in your working tree, it does
- not follow push/pull/clone like <code class="literal">.gitignore</code> can do. This is therefore
- the place to put exclude patterns that are local to your copy of the
- repo (i.e. <span class="emphasis"><em>not</em></span> shared between project participants), such as
- temporary backup files made by your editor (e.g. <code class="literal">*~</code>), etc.
-</dd><dt><span class="term">
-The file specified by the <code class="literal">core.excludesfile</code> config directive:
-</span></dt><dd>
- By setting the <code class="literal">core.excludesfile</code> config directive you can tell git
- where to find more exclude patterns (see <a href="git-config.html" target="_top">git-config(1)</a> for
- more information on configuration options). This config directive
- can be set in the per-repo <code class="literal">.git/config</code> file, in which case the
- exclude patterns will apply to that repo only. Alternatively, you
- can set the directive in the global <code class="literal">~/.gitconfig</code> file to apply
- the exclude pattern to all your git repos. As with the above
- <code class="literal">.git/info/exclude</code> (and, indeed, with git config directives in
- general), this directive does not follow push/pull/clone, but remain
- local to your repo(s).
-</dd></dl></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>In addition to the above alternatives, there are git commands that can take
-exclude patterns directly on the command line. See <a href="git-ls-files.html" target="_top">git-ls-files(1)</a>
-for an example of this.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="how-to-merge"></a>How to merge</h2></div></div></div><p>You can rejoin two diverging branches of development using
+*.[oa]</p></div><p>See <a href="gitignore.html" target="_top">gitignore(5)</a> for a detailed explanation of the syntax. You can
+also place .gitignore files in other directories in your working tree, and they
+will apply to those directories and their subdirectories. The <code class="literal">.gitignore</code>
+files can be added to your repository like any other files (just run <code class="literal">git add
+.gitignore</code> and <code class="literal">git commit</code>, as usual), which is convenient when the exclude
+patterns (such as patterns matching build output files) would also make sense
+for other users who clone your repository.</p><p>If you wish the exclude patterns to affect only certain repositories
+(instead of every repository for a given project), you may instead put
+them in a file in your repository named .git/info/exclude, or in any file
+specified by the <code class="literal">core.excludesfile</code> configuration variable. Some git
+commands can also take exclude patterns directly on the command line.
+See <a href="gitignore.html" target="_top">gitignore(5)</a> for the details.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="how-to-merge"></a>How to merge</h2></div></div></div><p>You can rejoin two diverging branches of development using
<a href="git-merge.html" target="_top">git-merge(1)</a>:</p><div class="literallayout"><p>$ git merge branchname</p></div><p>merges the development in the branch "branchname" into the current
branch. If there are conflicts—for example, if the same file is
modified in two different ways in the remote branch and the local
resolution, instead of creating a new commit, just run</p><div class="literallayout"><p>$ git am --resolved</p></div><p>and git will create the commit for you and continue applying the
remaining patches from the mailbox.</p><p>The final result will be a series of commits, one for each patch in
the original mailbox, with authorship and commit log message each
-taken from the message containing each patch.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="public-repositories"></a>Public git repositories</h2></div></div></div><p>Another way to submit changes to a project is to tell the maintainer of
-that project to pull the changes from your repository using git-pull[1].
-In the section "<a href="#getting-updates-with-git-pull" title="Getting updates with git pull">Getting updates with git pull</a>" we described this as a way to get updates from the "main"
-repository, but it works just as well in the other direction.</p><p>If you and the maintainer both have accounts on the same machine, then
+taken from the message containing each patch.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="public-repositories"></a>Public git repositories</h2></div></div></div><p>Another way to submit changes to a project is to tell the maintainer
+of that project to pull the changes from your repository using
+<a href="git-pull.html" target="_top">git-pull(1)</a>. In the section "<a href="#getting-updates-with-git-pull" title="Getting updates with git pull">Getting updates with git pull</a>" we described this as a way to get
+updates from the "main" repository, but it works just as well in the
+other direction.</p><p>If you and the maintainer both have accounts on the same machine, then
you can just pull changes from each other's repositories directly;
commands that accept repository URLs as arguments will also accept a
local directory name:</p><div class="literallayout"><p>$ git clone /path/to/repository<br>
$ cd work</p></div><p>Linus's tree will be stored in the remote branch named origin/master,
and can be updated using <a href="git-fetch.html" target="_top">git-fetch(1)</a>; you can track other
public trees using <a href="git-remote.html" target="_top">git-remote(1)</a> to set up a "remote" and
-git-fetch[1] to keep them up-to-date; see <a href="#repositories-and-branches" title="Chapter 1. Repositories and Branches">Chapter 1, <i>Repositories and Branches</i></a>.</p><p>Now create the branches in which you are going to work; these start out
+<a href="git-fetch.html" target="_top">git-fetch(1)</a> to keep them up-to-date; see
+<a href="#repositories-and-branches" title="Chapter 1. Repositories and Branches">Chapter 1, <i>Repositories and Branches</i></a>.</p><p>Now create the branches in which you are going to work; these start out
at the current tip of origin/master branch, and should be set up (using
the —track option to <a href="git-branch.html" target="_top">git-branch(1)</a>) to merge changes in from
Linus by default.</p><div class="literallayout"><p>$ git branch --track test origin/master<br>
$ gitk origin..mywork &</p></div><p>And browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
cherry-pick, and possibly modifying them as you go using commit —amend.
-The git-gui[1] command may also help as it allows you to individually
-select diff hunks for inclusion in the index (by right-clicking on the
-diff hunk and choosing "Stage Hunk for Commit").</p><p>Another technique is to use git-format-patch to create a series of
+The <a href="git-gui.html" target="_top">git-gui(1)</a> command may also help as it allows you to
+individually select diff hunks for inclusion in the index (by
+
right-clicking on the diff hunk and choosing "Stage Hunk for Commit").</p><p>Another technique is to use git-format-patch to create a series of
patches, then reset the state to before the patches:</p><div class="literallayout"><p>$ git format-patch origin<br>
$ git reset --hard origin</p></div><p>Then modify, reorder, or eliminate patches as preferred before applying
them again with <a href="git-am.html" target="_top">git-am(1)</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="patch-series-tools"></a>Other tools</h2></div></div></div><p>There are numerous other tools, such as StGIT, which exist for the
It will be useful to have a git repository to experiment with as you
read this manual.
-The best way to get one is by using the gitlink:git-clone[1] command
-to download a copy of an existing repository for a project that you
-are interested in. If you don't already have a project in mind, here
-are some interesting examples:
+The best way to get one is by using the gitlink:git-clone[1] command to
+download a copy of an existing repository. If you don't already have a
+project in mind, here are some interesting examples:
------------------------------------------------
# git itself (approx. 10MB download):
together with a special top-level directory named ".git", which
contains all the information about the history of the project.
-In most of the following, examples will be taken from one of the two
-repositories above.
-
[[how-to-check-out]]
How to check out a different version of a project
-------------------------------------------------
-Git is best thought of as a tool for storing the history of a
-collection of files. It stores the history as a compressed
-collection of interrelated snapshots (versions) of the project's
-contents.
+Git is best thought of as a tool for storing the history of a collection
+of files. It stores the history as a compressed collection of
+interrelated snapshots of the project's contents. In git each such
+version is called a <<def_commit,commit>>.
A single git repository may contain multiple branches. It keeps track
of them by keeping a list of <<def_head,heads>> which reference the
-latest version on each branch; the gitlink:git-branch[1] command shows
+latest commit on each branch; the gitlink:git-branch[1] command shows
you the list of branch heads:
------------------------------------------------
------------------------------------------------
$ git show
-commit 2b5f6dcce5bf94b9b119e9ed8d537098ec61c3d2
-Author: Jamal Hadi Salim <hadi@cyberus.ca>
-Date: Sat Dec 2 22:22:25 2006 -0800
-
- [XFRM]: Fix aevent structuring to be more complete.
-
- aevents can not uniquely identify an SA. We break the ABI with this
- patch, but consensus is that since it is not yet utilized by any
- (known) application then it is fine (better do it now than later).
-
- Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
- Signed-off-by: David S. Miller <davem@davemloft.net>
-
-diff --git a/Documentation/networking/xfrm_sync.txt b/Documentation/networking/xfrm_sync.txt
-index 8be626f..d7aac9d 100644
---- a/Documentation/networking/xfrm_sync.txt
-+++ b/Documentation/networking/xfrm_sync.txt
-@@ -47,10 +47,13 @@ aevent_id structure looks like:
-
- struct xfrm_aevent_id {
- struct xfrm_usersa_id sa_id;
-+ xfrm_address_t saddr;
- __u32 flags;
-+ __u32 reqid;
- };
-...
+commit 17cf781661e6d38f737f15f53ab552f1e95960d7
+Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)>
+Date: Tue Apr 19 14:11:06 2005 -0700
+
+ Remove duplicate getenv(DB_ENVIRONMENT) call
+
+ Noted by Tony Luck.
+
+diff --git a/init-db.c b/init-db.c
+index 65898fa..b002dc6 100644
+--- a/init-db.c
++++ b/init-db.c
+@@ -7,7 +7,7 @@
+
+ int main(int argc, char **argv)
+ {
+- char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
++ char *sha1_dir, *path;
+ int len, i;
+
+ if (mkdir(".git", 0755) < 0) {
------------------------------------------------
As you can see, a commit shows who made the latest change, what they
[[Finding-comments-with-given-content]]
Finding commits referencing a file with given content
------------------------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Somebody hands you a copy of a file, and asks which commits modified a
file such that it contained the given content either before or after the
is just a matter of 'not' calling "`git add`" on them. But it quickly becomes
annoying to have these untracked files lying around; e.g. they make
"`git add .`" and "`git commit -a`" practically useless, and they keep
-showing up in the output of "`git status`", etc.
+showing up in the output of "`git status`".
-Git therefore provides "exclude patterns" for telling git which files to
-actively ignore. Exclude patterns are thoroughly explained in the
-gitlink:gitignore[5] manual page, but the heart of the concept is simply
-a list of files which git should ignore. Entries in the list may contain
-globs to specify multiple files, or may be prefixed by "`!`" to
-explicitly include (un-ignore) a previously excluded (ignored) file
-(i.e. later exclude patterns override earlier ones). The following
-example should illustrate such patterns:
+You can tell git to ignore certain files by creating a file called .gitignore
+in the top level of your working directory, with contents such as:
-------------------------------------------------
# Lines starting with '#' are considered comments.
-# Ignore foo.txt.
+# Ignore any file named foo.txt.
foo.txt
# Ignore (generated) html files,
*.html
*.[oa]
-------------------------------------------------
-The next question is where to put these exclude patterns so that git can
-find them. Git looks for exclude patterns in the following files:
-
-`.gitignore` files in your working tree:::
- You may store multiple `.gitignore` files at various locations in your
- working tree. Each `.gitignore` file is applied to the directory where
- it's located, including its subdirectories. Furthermore, the
- `.gitignore` files can be tracked like any other files in your working
- tree; just do a "`git add .gitignore`" and commit. `.gitignore` is
- therefore the right place to put exclude patterns that are meant to
- be shared between all project participants, such as build output files
- (e.g. `\*.o`), etc.
-`.git/info/exclude` in your repo:::
- Exclude patterns in this file are applied to the working tree as a
- whole. Since the file is not located in your working tree, it does
- not follow push/pull/clone like `.gitignore` can do. This is therefore
- the place to put exclude patterns that are local to your copy of the
- repo (i.e. 'not' shared between project participants), such as
- temporary backup files made by your editor (e.g. `\*~`), etc.
-The file specified by the `core.excludesfile` config directive:::
- By setting the `core.excludesfile` config directive you can tell git
- where to find more exclude patterns (see gitlink:git-config[1] for
- more information on configuration options). This config directive
- can be set in the per-repo `.git/config` file, in which case the
- exclude patterns will apply to that repo only. Alternatively, you
- can set the directive in the global `~/.gitconfig` file to apply
- the exclude pattern to all your git repos. As with the above
- `.git/info/exclude` (and, indeed, with git config directives in
- general), this directive does not follow push/pull/clone, but remain
- local to your repo(s).
-
-[NOTE]
-In addition to the above alternatives, there are git commands that can take
-exclude patterns directly on the command line. See gitlink:git-ls-files[1]
-for an example of this.
+See gitlink:gitignore[5] for a detailed explanation of the syntax. You can
+also place .gitignore files in other directories in your working tree, and they
+will apply to those directories and their subdirectories. The `.gitignore`
+files can be added to your repository like any other files (just run `git add
+.gitignore` and `git commit`, as usual), which is convenient when the exclude
+patterns (such as patterns matching build output files) would also make sense
+for other users who clone your repository.
+
+If you wish the exclude patterns to affect only certain repositories
+(instead of every repository for a given project), you may instead put
+them in a file in your repository named .git/info/exclude, or in any file
+specified by the `core.excludesfile` configuration variable. Some git
+commands can also take exclude patterns directly on the command line.
+See gitlink:gitignore[5] for the details.
[[how-to-merge]]
How to merge
Public git repositories
-----------------------
-Another way to submit changes to a project is to tell the maintainer of
-that project to pull the changes from your repository using git-pull[1].
-In the section "<<getting-updates-with-git-pull, Getting updates with
-git pull>>" we described this as a way to get updates from the "main"
-repository, but it works just as well in the other direction.
+Another way to submit changes to a project is to tell the maintainer
+of that project to pull the changes from your repository using
+gitlink:git-pull[1]. In the section "<<getting-updates-with-git-pull,
+Getting updates with git pull>>" we described this as a way to get
+updates from the "main" repository, but it works just as well in the
+other direction.
If you and the maintainer both have accounts on the same machine, then
you can just pull changes from each other's repositories directly;
Linus's tree will be stored in the remote branch named origin/master,
and can be updated using gitlink:git-fetch[1]; you can track other
public trees using gitlink:git-remote[1] to set up a "remote" and
-git-fetch[1] to keep them up-to-date; see <<repositories-and-branches>>.
+gitlink:git-fetch[1] to keep them up-to-date; see
+<<repositories-and-branches>>.
Now create the branches in which you are going to work; these start out
at the current tip of origin/master branch, and should be set up (using
And browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
cherry-pick, and possibly modifying them as you go using commit --amend.
-The git-gui[1] command may also help as it allows you to individually
-select diff hunks for inclusion in the index (by right-clicking on the
-diff hunk and choosing "Stage Hunk for Commit").
+The gitlink:git-gui[1] command may also help as it allows you to
+individually select diff hunks for inclusion in the index (by
+right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
Another technique is to use git-format-patch to create a series of
patches, then reset the state to before the patches:
projects / git.git / commitdiff