OSDN Git Service

Add Git official document to help
[tortoisegit/TortoiseGitJp.git] / doc / source / en / TortoiseGit / git_doc / user-manual.xml
@@ -27,9 +27,9 @@ pages, or <ulink url="git-help.html">git-help(1)</ulink> command.  For example,
 without any explanation.</simpara>\r
 <simpara>Finally, see <xref linkend="todo"/> for ways that you can help make this manual more\r
 complete.</simpara>\r
-<section id="repositories-and-branches">\r
+<simplesect id="repositories-and-branches">\r
 <title>Repositories and Branches</title>\r
-<section id="how-to-get-a-git-repository">\r
+<simplesect id="how-to-get-a-git-repository">\r
 <title>How to get a git repository</title>\r
 <simpara>It will be useful to have a git repository to experiment with as you\r
 read this manual.</simpara>\r
@@ -48,8 +48,8 @@ directory, you will see that it contains a copy of the project files,
 called the <link linkend="def_working_tree">working tree</link>, together with a special\r
 top-level directory named ".git", which contains all the information\r
 about the history of the project.</simpara>\r
-</section>\r
-<section id="how-to-check-out">\r
+</simplesect>\r
+<simplesect id="how-to-check-out">\r
 <title>How to check out a different version of a project</title>\r
 <simpara>Git is best thought of as a tool for storing the history of a collection\r
 of files.  It stores the history as a compressed collection of\r
@@ -100,8 +100,8 @@ the current branch to point at v2.6.17 instead, with</simpara>
 particular point in history, then resetting that branch may leave you\r
 with no way to find the history it used to point to; so use this command\r
 carefully.</simpara>\r
-</section>\r
-<section id="understanding-commits">\r
+</simplesect>\r
+<simplesect id="understanding-commits">\r
 <title>Understanding History: Commits</title>\r
 <simpara>Every change in the history of a project is represented by a commit.\r
 The <ulink url="git-show.html">git-show(1)</ulink> command shows the most recent commit on the\r
@@ -143,7 +143,7 @@ without its name also changing.</simpara>
 <simpara>In fact, in <xref linkend="git-concepts"/> we shall see that everything stored in git\r
 history, including file data and directory contents, is stored in an object\r
 with a name that is a hash of its contents.</simpara>\r
-<section id="understanding-reachability">\r
+<simplesect id="understanding-reachability">\r
 <title>Understanding history: commits, parents, and reachability</title>\r
 <simpara>Every commit (except the very first commit in a project) also has a\r
 parent commit which shows what happened before this commit.\r
@@ -162,8 +162,8 @@ commits will help understand how the git organizes history.</simpara>
 if commit X is an ancestor of commit Y.  Equivalently, you could say\r
 that Y is a descendant of X, or that there is a chain of parents\r
 leading from commit Y to commit X.</simpara>\r
-</section>\r
-<section id="history-diagrams">\r
+</simplesect>\r
+<simplesect id="history-diagrams">\r
 <title>Understanding history: History diagrams</title>\r
 <simpara>We will sometimes represent git history using diagrams like the one\r
 below.  Commits are shown as "o", and the links between them with\r
@@ -175,8 +175,8 @@ lines drawn with - / and \.  Time goes left to right:</simpara>
          o--o--o &lt;-- Branch B</literallayout>\r
 <simpara>If we need to talk about a particular commit, the character "o" may\r
 be replaced with another letter or number.</simpara>\r
-</section>\r
-<section id="what-is-a-branch">\r
+</simplesect>\r
+<simplesect id="what-is-a-branch">\r
 <title>Understanding history: What is a branch?</title>\r
 <simpara>When we need to be precise, we will use the word "branch" to mean a line\r
 of development, and "branch head" (or just "head") to mean a reference\r
@@ -186,9 +186,9 @@ the line of three commits leading up to that point as all being part of
 "branch A".</simpara>\r
 <simpara>However, when no confusion will result, we often just use the term\r
 "branch" both for branches and for branch heads.</simpara>\r
-</section>\r
-</section>\r
-<section id="manipulating-branches">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="manipulating-branches">\r
 <title>Manipulating branches</title>\r
 <simpara>Creating, deleting, and modifying branches is quick and easy; here&#8217;s\r
 a summary of the commands:</simpara>\r
@@ -280,8 +280,8 @@ branch.  In fact, git uses a file named "HEAD" in the .git directory to
 remember which branch is current:</simpara>\r
 <literallayout>$ cat .git/HEAD\r
 ref: refs/heads/master</literallayout>\r
-</section>\r
-<section id="detached-head">\r
+</simplesect>\r
+<simplesect id="detached-head">\r
 <title>Examining an old version without creating a new branch</title>\r
 <simpara>The git-checkout command normally expects a branch head, but will also\r
 accept an arbitrary commit; for example, you can check out the commit\r
@@ -303,8 +303,8 @@ $ git branch
 <simpara>This is an easy way to check out a particular version without having to\r
 make up a name for the new branch.   You can still create a new branch\r
 (or tag) for this version later if you decide to.</simpara>\r
-</section>\r
-<section id="examining-remote-branches">\r
+</simplesect>\r
+<simplesect id="examining-remote-branches">\r
 <title>Examining branches from a remote repository</title>\r
 <simpara>The "master" branch that was created at the time you cloned is a copy\r
 of the HEAD in the repository that you cloned from.  That repository\r
@@ -325,8 +325,8 @@ examine them on a branch of your own, just as you would a tag:</simpara>
 <literallayout>$ git checkout -b my-todo-copy origin/todo</literallayout>\r
 <simpara>Note that the name "origin" is just the name that git uses by default\r
 to refer to the repository that you cloned from.</simpara>\r
-</section>\r
-<section id="how-git-stores-references">\r
+</simplesect>\r
+<simplesect id="how-git-stores-references">\r
 <title>Naming branches, tags, and other references</title>\r
 <simpara>Branches, remote-tracking branches, and tags are all references to\r
 commits.  All references are named with a slash-separated path name\r
@@ -362,8 +362,8 @@ is usually a shortcut for the HEAD branch in the repository "origin".</simpara>
 the order it uses to decide which to choose when there are multiple\r
 references with the same shorthand name, see the "SPECIFYING\r
 REVISIONS" section of <ulink url="git-rev-parse.html">git-rev-parse(1)</ulink>.</simpara>\r
-</section>\r
-<section id="Updating-a-repository-With-git-fetch">\r
+</simplesect>\r
+<simplesect id="Updating-a-repository-With-git-fetch">\r
 <title>Updating a repository with git-fetch</title>\r
 <simpara>Eventually the developer cloned from will do additional work in her\r
 repository, creating new commits and advancing the branches to point\r
@@ -372,8 +372,8 @@ at the new commits.</simpara>
 remote-tracking branches to the latest version found in her\r
 repository.  It will not touch any of your own branches&#8212;not even the\r
 "master" branch that was created for you on clone.</simpara>\r
-</section>\r
-<section id="fetching-branches">\r
+</simplesect>\r
+<simplesect id="fetching-branches">\r
 <title>Fetching branches from other repositories</title>\r
 <simpara>You can also track branches from repositories other than the one you\r
 cloned from, using <ulink url="git-remote.html">git-remote(1)</ulink>:</simpara>\r
@@ -400,9 +400,9 @@ a new stanza:</simpara>
 or delete these configuration options by editing .git/config with a\r
 text editor.  (See the "CONFIGURATION FILE" section of\r
 <ulink url="git-config.html">git-config(1)</ulink> for details.)</simpara>\r
-</section>\r
-</section>\r
-<section id="exploring-git-history">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="exploring-git-history">\r
 <title>Exploring git history</title>\r
 <simpara>Git is best thought of as a tool for storing the history of a\r
 collection of files.  It does this by storing compressed snapshots of\r
@@ -412,7 +412,7 @@ the relationships between these snapshots.</simpara>
 history of a project.</simpara>\r
 <simpara>We start with one specialized tool that is useful for finding the\r
 commit that introduced a bug into a project.</simpara>\r
-<section id="using-bisect">\r
+<simplesect id="using-bisect">\r
 <title>How to use bisect to find a regression</title>\r
 <simpara>Suppose version 2.6.18 of your project worked, but the version at\r
 "master" crashes.  Sometimes the best way to find the cause of such a\r
@@ -464,8 +464,8 @@ bad one between some first skipped commits and a later bad commit.</simpara>
 test script that can tell a good from a bad commit. See\r
 <ulink url="git-bisect.html">git-bisect(1)</ulink> for more information about this and other "git\r
 bisect" features.</simpara>\r
-</section>\r
-<section id="naming-commits">\r
+</simplesect>\r
+<simplesect id="naming-commits">\r
 <title>Naming commits</title>\r
 <simpara>We have seen several ways of naming commits already:</simpara>\r
 <itemizedlist>\r
@@ -524,8 +524,8 @@ occasionally useful for translating some name for a commit to the object
 name for that commit:</simpara>\r
 <literallayout>$ git rev-parse origin\r
 e05db0fd4f31dde7005f075a84f96b360d05984b</literallayout>\r
-</section>\r
-<section id="creating-tags">\r
+</simplesect>\r
+<simplesect id="creating-tags">\r
 <title>Creating tags</title>\r
 <simpara>We can also create a tag to refer to a particular commit; after\r
 running</simpara>\r
@@ -535,8 +535,8 @@ running</simpara>
 comment with the tag, and possibly sign it cryptographically, then you\r
 should create a tag object instead; see the <ulink url="git-tag.html">git-tag(1)</ulink> man page\r
 for details.</simpara>\r
-</section>\r
-<section id="browsing-revisions">\r
+</simplesect>\r
+<simplesect id="browsing-revisions">\r
 <title>Browsing revisions</title>\r
 <simpara>The <ulink url="git-log.html">git-log(1)</ulink> command can show lists of commits.  On its\r
 own, it shows all commits reachable from the parent commit; but you\r
@@ -562,8 +562,8 @@ display options.</simpara>
 backwards through the parents; however, since git history can contain\r
 multiple independent lines of development, the particular order that\r
 commits are listed in may be somewhat arbitrary.</simpara>\r
-</section>\r
-<section id="generating-diffs">\r
+</simplesect>\r
+<simplesect id="generating-diffs">\r
 <title>Generating diffs</title>\r
 <simpara>You can generate diffs between any two versions using\r
 <ulink url="git-diff.html">git-diff(1)</ulink>:</simpara>\r
@@ -577,8 +577,8 @@ use <ulink url="git-format-patch.html">git-format-patch(1)</ulink>:</simpara>
 <literallayout>$ git format-patch master..test</literallayout>\r
 <simpara>will generate a file with a patch for each commit reachable from test\r
 but not from master.</simpara>\r
-</section>\r
-<section id="viewing-old-file-versions">\r
+</simplesect>\r
+<simplesect id="viewing-old-file-versions">\r
 <title>Viewing old file versions</title>\r
 <simpara>You can always view an old version of a file by just checking out the\r
 correct revision first.  But sometimes it is more convenient to be\r
@@ -587,10 +587,10 @@ anything out; this command does that:</simpara>
 <literallayout>$ git show v2.5:fs/locks.c</literallayout>\r
 <simpara>Before the colon may be anything that names a commit, and after it\r
 may be any path to a file tracked by git.</simpara>\r
-</section>\r
-<section id="history-examples">\r
+</simplesect>\r
+<simplesect id="history-examples">\r
 <title>Examples</title>\r
-<section id="counting-commits-on-a-branch">\r
+<simplesect id="counting-commits-on-a-branch">\r
 <title>Counting the number of commits on a branch</title>\r
 <simpara>Suppose you want to know how many commits you&#8217;ve made on "mybranch"\r
 since it diverged from "origin":</simpara>\r
@@ -599,8 +599,8 @@ since it diverged from "origin":</simpara>
 lower-level command <ulink url="git-rev-list.html">git-rev-list(1)</ulink>, which just lists the SHA1&#8217;s\r
 of all the given commits:</simpara>\r
 <literallayout>$ git rev-list origin..mybranch | wc -l</literallayout>\r
-</section>\r
-<section id="checking-for-equal-branches">\r
+</simplesect>\r
+<simplesect id="checking-for-equal-branches">\r
 <title>Check whether two branches point at the same history</title>\r
 <simpara>Suppose you want to check whether two branches point at the same point\r
 in history.</simpara>\r
@@ -618,8 +618,8 @@ contained reachable from either one reference or the other but not
 both: so</simpara>\r
 <literallayout>$ git log origin...master</literallayout>\r
 <simpara>will return no commits when the two branches are equal.</simpara>\r
-</section>\r
-<section id="finding-tagged-descendants">\r
+</simplesect>\r
+<simplesect id="finding-tagged-descendants">\r
 <title>Find first tagged version including a given fix</title>\r
 <simpara>Suppose you know that the commit e05db0fd fixed a certain problem.\r
 You&#8217;d like to find the earliest tagged release that contains that\r
@@ -668,8 +668,8 @@ available
 available</literallayout>\r
 <simpara>Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and\r
 from v1.5.0-rc2, but not from v1.5.0-rc0.</simpara>\r
-</section>\r
-<section id="showing-commits-unique-to-a-branch">\r
+</simplesect>\r
+<simplesect id="showing-commits-unique-to-a-branch">\r
 <title>Showing commits unique to a given branch</title>\r
 <simpara>Suppose you would like to see all the commits reachable from the branch\r
 head named "master" but not from any other head in your repository.</simpara>\r
@@ -697,8 +697,8 @@ commits reachable from some head but not from any tag in the repository:</simpar
 <literallayout>$ gitk $( git show-ref --heads ) --not  $( git show-ref --tags )</literallayout>\r
 <simpara>(See <ulink url="git-rev-parse.html">git-rev-parse(1)</ulink> for explanations of commit-selecting\r
 syntax such as <literal>--not</literal>.)</simpara>\r
-</section>\r
-<section id="making-a-release">\r
+</simplesect>\r
+<simplesect id="making-a-release">\r
 <title>Creating a changelog and tarball for a software release</title>\r
 <simpara>The <ulink url="git-archive.html">git-archive(1)</ulink> command can create a tar or zip archive from\r
 any version of a project; for example:</simpara>\r
@@ -724,8 +724,8 @@ echo "git shortlog --no-merges v$new ^v$last &gt; ../ShortLog"
 echo "git diff --stat --summary -M v$last v$new &gt; ../diffstat-$new"</literallayout>\r
 <simpara>and then he just cut-and-pastes the output commands after verifying that\r
 they look OK.</simpara>\r
-</section>\r
-<section id="Finding-comments-With-given-Content">\r
+</simplesect>\r
+<simplesect id="Finding-comments-With-given-Content">\r
 <title>Finding commits referencing a file with given content</title>\r
 <simpara>Somebody hands you a copy of a file, and asks which commits modified a\r
 file such that it contained the given content either before or after the\r
@@ -735,12 +735,12 @@ commit.  You can find out with this:</simpara>
 <simpara>Figuring out why this works is left as an exercise to the (advanced)\r
 student.  The <ulink url="git-log.html">git-log(1)</ulink>, <ulink url="git-diff-tree.html">git-diff-tree(1)</ulink>, and\r
 <ulink url="git-hash-object.html">git-hash-object(1)</ulink> man pages may prove helpful.</simpara>\r
-</section>\r
-</section>\r
-</section>\r
-<section id="Developing-With-git">\r
+</simplesect>\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="Developing-With-git">\r
 <title>Developing with git</title>\r
-<section id="telling-git-your-name">\r
+<simplesect id="telling-git-your-name">\r
 <title>Telling git your name</title>\r
 <simpara>Before creating any commits, you should introduce yourself to git.  The\r
 easiest way to do so is to make sure the following lines appear in a\r
@@ -750,8 +750,8 @@ file named .gitconfig in your home directory:</simpara>
         email = you@yourdomain.example.com</literallayout>\r
 <simpara>(See the "CONFIGURATION FILE" section of <ulink url="git-config.html">git-config(1)</ulink> for\r
 details on the configuration file.)</simpara>\r
-</section>\r
-<section id="creating-a-new-repository">\r
+</simplesect>\r
+<simplesect id="creating-a-new-repository">\r
 <title>Creating a new repository</title>\r
 <simpara>Creating a new repository from scratch is very easy:</simpara>\r
 <literallayout>$ mkdir project\r
@@ -763,8 +763,8 @@ $ cd project
 $ git init\r
 $ git add . # include everything below ./ in the first commit:\r
 $ git commit</literallayout>\r
-</section>\r
-<section id="how-to-make-a-commit">\r
+</simplesect>\r
+<simplesect id="how-to-make-a-commit">\r
 <title>How to make a commit</title>\r
 <simpara>Creating a new commit takes three steps:</simpara>\r
 <orderedlist numeration="arabic">\r
@@ -833,8 +833,8 @@ $ git status        # a brief per-file summary of the above.</literallayout>
 the index and the working tree files, and individually select diff hunks\r
 for inclusion in the index (by right-clicking on the diff hunk and\r
 choosing "Stage Hunk For Commit").</simpara>\r
-</section>\r
-<section id="creating-good-commit-messages">\r
+</simplesect>\r
+<simplesect id="creating-good-commit-messages">\r
 <title>Creating good commit messages</title>\r
 <simpara>Though not required, it&#8217;s a good idea to begin the commit message\r
 with a single short (less than 50 character) line summarizing the\r
@@ -842,8 +842,8 @@ change, followed by a blank line and then a more thorough
 description.  Tools that turn commits into email, for example, use\r
 the first line on the Subject line and the rest of the commit in the\r
 body.</simpara>\r
-</section>\r
-<section id="ignoring-files">\r
+</simplesect>\r
+<simplesect id="ignoring-files">\r
 <title>Ignoring files</title>\r
 <simpara>A project will often generate files that you do <emphasis>not</emphasis> want to track with git.\r
 This typically includes files generated by a build process or temporary\r
@@ -876,8 +876,8 @@ them in a file in your repository named .git/info/exclude, or in any file
 specified by the <literal>core.excludesfile</literal> configuration variable.  Some git\r
 commands can also take exclude patterns directly on the command line.\r
 See <ulink url="gitignore.html">gitignore(5)</ulink> for the details.</simpara>\r
-</section>\r
-<section id="how-to-merge">\r
+</simplesect>\r
+<simplesect id="how-to-merge">\r
 <title>How to merge</title>\r
 <simpara>You can rejoin two diverging branches of development using\r
 <ulink url="git-merge.html">git-merge(1)</ulink>:</simpara>\r
@@ -898,8 +898,8 @@ creating a new file.</simpara>
 <simpara>If you examine the resulting commit using gitk, you will see that it\r
 has two parents, one pointing to the top of the current branch, and\r
 one to the top of the other branch.</simpara>\r
-</section>\r
-<section id="resolving-a-merge">\r
+</simplesect>\r
+<simplesect id="resolving-a-merge">\r
 <title>Resolving a merge</title>\r
 <simpara>When a merge isn&#8217;t resolved automatically, git leaves the index and\r
 the working tree in a special state that gives you all the\r
@@ -925,7 +925,7 @@ default message unchanged, but you may add additional commentary of
 your own if desired.</simpara>\r
 <simpara>The above is all you need to know to resolve a simple merge.  But git\r
 also provides more information to help resolve conflicts:</simpara>\r
-<section id="conflict-resolution">\r
+<simplesect id="conflict-resolution">\r
 <title>Getting conflict-resolution help during a merge</title>\r
 <simpara>All of the changes that git was able to merge automatically are\r
 already added to the index file, so <ulink url="git-diff.html">git-diff(1)</ulink> shows only\r
@@ -996,9 +996,9 @@ unmerged files using external tools such as Emacs or kdiff3.</simpara>
 <literallayout>$ git add file.txt</literallayout>\r
 <simpara>the different stages of that file will be "collapsed", after which\r
 git-diff will (by default) no longer show diffs for that file.</simpara>\r
-</section>\r
-</section>\r
-<section id="undoing-a-merge">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="undoing-a-merge">\r
 <title>Undoing a merge</title>\r
 <simpara>If you get stuck and decide to just give up and throw the whole mess\r
 away, you can always return to the pre-merge state with</simpara>\r
@@ -1009,8 +1009,8 @@ away, you can always return to the pre-merge state with</simpara>
 throw away a commit you have already committed if that commit may\r
 itself have been merged into another branch, as doing so may confuse\r
 further merges.</simpara>\r
-</section>\r
-<section id="fast-forwards">\r
+</simplesect>\r
+<simplesect id="fast-forwards">\r
 <title>Fast-forward merges</title>\r
 <simpara>There is one special case not mentioned above, which is treated\r
 differently.  Normally, a merge results in a merge commit, with two\r
@@ -1021,8 +1021,8 @@ commit present in the one is already contained in the other&#8212;then git
 just performs a "fast forward"; the head of the current branch is moved\r
 forward to point at the head of the merged-in branch, without any new\r
 commits being created.</simpara>\r
-</section>\r
-<section id="fixing-mistakes">\r
+</simplesect>\r
+<simplesect id="fixing-mistakes">\r
 <title>Fixing mistakes</title>\r
 <simpara>If you&#8217;ve messed up the working tree, but haven&#8217;t yet committed your\r
 mistake, you can return the entire working tree to the last committed\r
@@ -1048,7 +1048,7 @@ You can go back and modify the old commit.  You should
 </simpara>\r
 </listitem>\r
 </orderedlist>\r
-<section id="reverting-a-commit">\r
+<simplesect id="reverting-a-commit">\r
 <title>Fixing a mistake with a new commit</title>\r
 <simpara>Creating a new commit that reverts an earlier change is very easy;\r
 just pass the <ulink url="git-revert.html">git-revert(1)</ulink> command a reference to the bad\r
@@ -1062,8 +1062,8 @@ will be given a chance to edit the commit message for the new commit.</simpara>
 intact any changes made since then.  If more recent changes overlap\r
 with the changes to be reverted, then you will be asked to fix\r
 conflicts manually, just as in the case of <link linkend="resolving-a-merge">resolving a merge</link>.</simpara>\r
-</section>\r
-<section id="fixing-a-mistake-by-rewriting-history">\r
+</simplesect>\r
+<simplesect id="fixing-a-mistake-by-rewriting-history">\r
 <title>Fixing a mistake by rewriting history</title>\r
 <simpara>If the problematic commit is the most recent commit, and you have not\r
 yet made that commit public, then you may just\r
@@ -1080,8 +1080,8 @@ that case.</simpara>
 <simpara>It is also possible to replace commits further back in the history, but\r
 this is an advanced topic to be left for\r
 <link linkend="cleaning-up-history">another chapter</link>.</simpara>\r
-</section>\r
-<section id="checkout-of-path">\r
+</simplesect>\r
+<simplesect id="checkout-of-path">\r
 <title>Checking out an old version of a file</title>\r
 <simpara>In the process of undoing a previous bad change, you may find it\r
 useful to check out an older version of a particular file using\r
@@ -1096,8 +1096,8 @@ modifying the working directory, you can do that with
 <ulink url="git-show.html">git-show(1)</ulink>:</simpara>\r
 <literallayout>$ git show HEAD^:path/to/file</literallayout>\r
 <simpara>which will display the given version of the file.</simpara>\r
-</section>\r
-<section id="interrupted-work">\r
+</simplesect>\r
+<simplesect id="interrupted-work">\r
 <title>Temporarily setting aside work in progress</title>\r
 <simpara>While you are in the middle of working on something complicated, you\r
 find an unrelated but obvious and trivial bug.  You would like to fix it\r
@@ -1114,9 +1114,9 @@ $ git commit -a -m "blorpl: typofix"</literallayout>
 <simpara>After that, you can go back to what you were working on with\r
 <literal>git stash apply</literal>:</simpara>\r
 <literallayout>$ git stash apply</literallayout>\r
-</section>\r
-</section>\r
-<section id="ensuring-good-performance">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="ensuring-good-performance">\r
 <title>Ensuring good performance</title>\r
 <simpara>On large repositories, git depends on compression to keep the history\r
 information from taking up too much space on disk or in memory.</simpara>\r
@@ -1125,10 +1125,10 @@ should occasionally run <ulink url="git-gc.html">git-gc(1)</ulink>:</simpara>
 <literallayout>$ git gc</literallayout>\r
 <simpara>to recompress the archive.  This can be very time-consuming, so\r
 you may prefer to run git-gc when you are not doing other work.</simpara>\r
-</section>\r
-<section id="ensuring-reliability">\r
+</simplesect>\r
+<simplesect id="ensuring-reliability">\r
 <title>Ensuring reliability</title>\r
-<section id="checking-for-corruption">\r
+<simplesect id="checking-for-corruption">\r
 <title>Checking the repository for corruption</title>\r
 <simpara>The <ulink url="git-fsck.html">git-fsck(1)</ulink> command runs a number of self-consistency checks\r
 on the repository, and reports on any problems.  This may take some\r
@@ -1146,10 +1146,10 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
 <simpara>Dangling objects are not a problem.  At worst they may take up a little\r
 extra disk space.  They can sometimes provide a last-resort method for\r
 recovering lost work&#8212;see <xref linkend="dangling-objects"/> for details.</simpara>\r
-</section>\r
-<section id="recovering-lost-changes">\r
+</simplesect>\r
+<simplesect id="recovering-lost-changes">\r
 <title>Recovering lost changes</title>\r
-<section id="reflogs">\r
+<simplesect id="reflogs">\r
 <title>Reflogs</title>\r
 <simpara>Say you modify a branch with <literal><ulink url="git-reset.html">git-reset(1)</ulink> --hard</literal>, and then\r
 realize that the branch was the only reference you had to that point in\r
@@ -1179,8 +1179,8 @@ section of <ulink url="git-rev-parse.html">git-rev-parse(1)</ulink> for details.
 While normal history is shared by every repository that works on the\r
 same project, the reflog history is not shared: it tells you only about\r
 how the branches in your local repository have changed over time.</simpara>\r
-</section>\r
-<section id="dangling-object-recovery">\r
+</simplesect>\r
+<simplesect id="dangling-object-recovery">\r
 <title>Examining dangling objects</title>\r
 <simpara>In some situations the reflog may not be able to save you.  For example,\r
 suppose you delete a branch, then realize you need the history it\r
@@ -1208,13 +1208,13 @@ reference pointing to it, for example, a new branch:</simpara>
 <literallayout>$ git branch recovered-branch 7281251ddd</literallayout>\r
 <simpara>Other types of dangling objects (blobs and trees) are also possible, and\r
 dangling objects can arise in other situations.</simpara>\r
-</section>\r
-</section>\r
-</section>\r
-</section>\r
-<section id="sharing-development">\r
+</simplesect>\r
+</simplesect>\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="sharing-development">\r
 <title>Sharing development with others</title>\r
-<section id="getting-updates-With-git-pull">\r
+<simplesect id="getting-updates-With-git-pull">\r
 <title>Getting updates with git-pull</title>\r
 <simpara>After you clone a repository and make a few changes of your own, you\r
 may wish to check the original repository for updates and merge them\r
@@ -1248,8 +1248,8 @@ the commands</simpara>
 <literallayout>$ git pull . branch\r
 $ git merge branch</literallayout>\r
 <simpara>are roughly equivalent.  The former is actually very commonly used.</simpara>\r
-</section>\r
-<section id="submitting-patches">\r
+</simplesect>\r
+<simplesect id="submitting-patches">\r
 <title>Submitting patches to a project</title>\r
 <simpara>If you just have a few changes, the simplest way to submit them may\r
 just be to send them as patches in email:</simpara>\r
@@ -1262,8 +1262,8 @@ hand.  However, if you have a lot to send at once, you may prefer to
 use the <ulink url="git-send-email.html">git-send-email(1)</ulink> script to automate the process.\r
 Consult the mailing list for your project first to determine how they\r
 prefer such patches be handled.</simpara>\r
-</section>\r
-<section id="importing-patches">\r
+</simplesect>\r
+<simplesect id="importing-patches">\r
 <title>Importing patches to a project</title>\r
 <simpara>Git also provides a tool called <ulink url="git-am.html">git-am(1)</ulink> (am stands for\r
 "apply mailbox"), for importing such an emailed series of patches.\r
@@ -1283,8 +1283,8 @@ remaining patches from the mailbox.</simpara>
 <simpara>The final result will be a series of commits, one for each patch in\r
 the original mailbox, with authorship and commit log message each\r
 taken from the message containing each patch.</simpara>\r
-</section>\r
-<section id="public-repositories">\r
+</simplesect>\r
+<simplesect id="public-repositories">\r
 <title>Public git repositories</title>\r
 <simpara>Another way to submit changes to a project is to tell the maintainer\r
 of that project to pull the changes from your repository using\r
@@ -1321,7 +1321,7 @@ your personal repo ------------------&gt; your public repo
       |               they push             V\r
 their public repo &lt;------------------- their repo</literallayout>\r
 <simpara>We explain how to do this in the following sections.</simpara>\r
-<section id="setting-up-a-public-repository">\r
+<simplesect id="setting-up-a-public-repository">\r
 <title>Setting up a public repository</title>\r
 <simpara>Assume your personal repository is in the directory ~/proj.  We\r
 first create a new clone of the repository and tell git-daemon that it\r
@@ -1334,8 +1334,8 @@ around it.</simpara>
 <simpara>Next, copy proj.git to the server where you plan to host the\r
 public repository.  You can use scp, rsync, or whatever is most\r
 convenient.</simpara>\r
-</section>\r
-<section id="exporting-via-git">\r
+</simplesect>\r
+<simplesect id="exporting-via-git">\r
 <title>Exporting a git repository via the git protocol</title>\r
 <simpara>This is the preferred method.</simpara>\r
 <simpara>If someone else administers the server, they should tell you what\r
@@ -1350,8 +1350,8 @@ arguments will further restrict the exports to those paths.</simpara>
 <simpara>You can also run git-daemon as an inetd service; see the\r
 <ulink url="git-daemon.html">git-daemon(1)</ulink> man page for details.  (See especially the\r
 examples section.)</simpara>\r
-</section>\r
-<section id="exporting-via-http">\r
+</simplesect>\r
+<simplesect id="exporting-via-http">\r
 <title>Exporting a git repository via http</title>\r
 <simpara>The git protocol gives better performance and reliability, but on a\r
 host with a web server set up, http exports may be simpler to set up.</simpara>\r
@@ -1371,8 +1371,8 @@ clone or pull from that URL, for example with a command line like:</simpara>
 <ulink url="howto/setup-git-server-over-http.txt">setup-git-server-over-http</ulink>\r
 for a slightly more sophisticated setup using WebDAV which also\r
 allows pushing over http.)</simpara>\r
-</section>\r
-<section id="pushing-changes-to-a-public-repository">\r
+</simplesect>\r
+<simplesect id="pushing-changes-to-a-public-repository">\r
 <title>Pushing changes to a public repository</title>\r
 <simpara>Note that the two techniques outlined above (exporting via\r
 <link linkend="exporting-via-http">http</link> or <link linkend="exporting-via-git">git</link>) allow other\r
@@ -1404,8 +1404,8 @@ EOF</literallayout>
 <simpara>See the explanations of the remote.&lt;name&gt;.url, branch.&lt;name&gt;.remote,\r
 and remote.&lt;name&gt;.push options in <ulink url="git-config.html">git-config(1)</ulink> for\r
 details.</simpara>\r
-</section>\r
-<section id="forcing-push">\r
+</simplesect>\r
+<simplesect id="forcing-push">\r
 <title>What to do when a push fails</title>\r
 <simpara>If a push would not result in a <link linkend="fast-forwards">fast forward</link> of the\r
 remote branch, then it will fail with an error like:</simpara>\r
@@ -1450,8 +1450,8 @@ solution is to retry the push after first updating your work: either by a
 pull, or by a fetch followed by a rebase; see the\r
 <link linkend="setting-up-a-shared-repository">next section</link> and\r
 <ulink url="gitcvs-migration.html">gitcvs-migration(7)</ulink> for more.</simpara>\r
-</section>\r
-<section id="setting-up-a-shared-repository">\r
+</simplesect>\r
+<simplesect id="setting-up-a-shared-repository">\r
 <title>Setting up a shared repository</title>\r
 <simpara>Another way to collaborate is by using a model similar to that\r
 commonly used in CVS, where several developers with special rights\r
@@ -1491,17 +1491,17 @@ The lack of a central group of "committers" means there is
 </simpara>\r
 </listitem>\r
 </itemizedlist>\r
-</section>\r
-<section id="setting-up-gitweb">\r
+</simplesect>\r
+<simplesect id="setting-up-gitweb">\r
 <title>Allowing web browsing of a repository</title>\r
 <simpara>The gitweb cgi script provides users an easy way to browse your\r
 project&#8217;s files and history without having to install git; see the file\r
 gitweb/INSTALL in the git source tree for instructions on setting it up.</simpara>\r
-</section>\r
-</section>\r
-<section id="sharing-development-examples">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="sharing-development-examples">\r
 <title>Examples</title>\r
-<section id="maintaining-topic-branches">\r
+<simplesect id="maintaining-topic-branches">\r
 <title>Maintaining topic branches for a Linux subsystem maintainer</title>\r
 <simpara>This describes how Tony Luck uses git in his role as maintainer of the\r
 IA64 architecture for the Linux kernel.</simpara>\r
@@ -1714,17 +1714,17 @@ do
         esac\r
         git log origin/master..$branch | git shortlog\r
 done</literallayout>\r
-</section>\r
-</section>\r
-</section>\r
-<section id="cleaning-up-history">\r
+</simplesect>\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="cleaning-up-history">\r
 <title>Rewriting history and maintaining patch series</title>\r
 <simpara>Normally commits are only added to a project, never taken away or\r
 replaced.  Git is designed with this assumption, and violating it will\r
 cause git&#8217;s merge machinery (for example) to do the wrong thing.</simpara>\r
 <simpara>However, there is a situation in which it can be useful to violate this\r
 assumption.</simpara>\r
-<section id="patch-series">\r
+<simplesect id="patch-series">\r
 <title>Creating the perfect patch series</title>\r
 <simpara>Suppose you are a contributor to a large project, and you want to add a\r
 complicated feature, and to present it to the other developers in a way\r
@@ -1764,8 +1764,8 @@ The complete series produces the same end result as your own
 <simpara>We will introduce some tools that can help you do this, explain how to\r
 use them, and then explain some of the problems that can arise because\r
 you are rewriting history.</simpara>\r
-</section>\r
-<section id="using-git-rebase">\r
+</simplesect>\r
+<simplesect id="using-git-rebase">\r
 <title>Keeping a patch series up to date using git-rebase</title>\r
 <simpara>Suppose that you create a branch "mywork" on a remote-tracking branch\r
 "origin", and create some commits on top of it:</simpara>\r
@@ -1811,8 +1811,8 @@ running git-commit, just run</simpara>
 <simpara>At any point you may use the <literal>--abort</literal> option to abort this process and\r
 return mywork to the state it had before you started the rebase:</simpara>\r
 <literallayout>$ git rebase --abort</literallayout>\r
-</section>\r
-<section id="rewriting-one-commit">\r
+</simplesect>\r
+<simplesect id="rewriting-one-commit">\r
 <title>Rewriting a single commit</title>\r
 <simpara>We saw in <xref linkend="fixing-a-mistake-by-rewriting-history"/> that you can replace the\r
 most recent commit using</simpara>\r
@@ -1839,8 +1839,8 @@ then clean up with</simpara>
 <simpara>Note that the immutable nature of git history means that you haven&#8217;t really\r
 "modified" existing commits; instead, you have replaced the old commits with\r
 new commits having new object names.</simpara>\r
-</section>\r
-<section id="reordering-patch-series">\r
+</simplesect>\r
+<simplesect id="reordering-patch-series">\r
 <title>Reordering or selecting from a patch series</title>\r
 <simpara>Given one existing commit, the <ulink url="git-cherry-pick.html">git-cherry-pick(1)</ulink> command\r
 allows you to apply the change introduced by that commit and create a\r
@@ -1860,14 +1860,14 @@ patches, then reset the state to before the patches:</simpara>
 $ git reset --hard origin</literallayout>\r
 <simpara>Then modify, reorder, or eliminate patches as preferred before applying\r
 them again with <ulink url="git-am.html">git-am(1)</ulink>.</simpara>\r
-</section>\r
-<section id="patch-series-tools">\r
+</simplesect>\r
+<simplesect id="patch-series-tools">\r
 <title>Other tools</title>\r
 <simpara>There are numerous other tools, such as StGIT, which exist for the\r
 purpose of maintaining a patch series.  These are outside of the scope of\r
 this manual.</simpara>\r
-</section>\r
-<section id="problems-With-rewriting-history">\r
+</simplesect>\r
+<simplesect id="problems-With-rewriting-history">\r
 <title>Problems with rewriting history</title>\r
 <simpara>The primary problem with rewriting the history of a branch has to do\r
 with merging.  Suppose somebody fetches your branch and merges it into\r
@@ -1899,8 +1899,8 @@ order to examine or test them, but they should not attempt to pull such
 branches into their own work.</simpara>\r
 <simpara>For true distributed development that supports proper merging,\r
 published branches should never be rewritten.</simpara>\r
-</section>\r
-<section id="bisect-merges">\r
+</simplesect>\r
+<simplesect id="bisect-merges">\r
 <title>Why bisecting merge commits can be harder than bisecting linear history</title>\r
 <simpara>The <ulink url="git-bisect.html">git-bisect(1)</ulink> command correctly handles history that\r
 includes merge commits.  However, when the commit that it finds is a\r
@@ -1948,11 +1948,11 @@ and understanding why Y* was broken would probably be easier.</simpara>
 working on an otherwise merge-heavy project, keep the history\r
 linear by rebasing against the latest upstream version before\r
 publishing.</simpara>\r
-</section>\r
-</section>\r
-<section id="advanced-branch-management">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="advanced-branch-management">\r
 <title>Advanced branch management</title>\r
-<section id="fetching-individual-branches">\r
+<simplesect id="fetching-individual-branches">\r
 <title>Fetching individual branches</title>\r
 <simpara>Instead of using <ulink url="git-remote.html">git-remote(1)</ulink>, you can also choose just\r
 to update one branch at a time, and to store it locally under an\r
@@ -1969,8 +1969,8 @@ branch named "master" from the repository at the given URL.  If you
 already have a branch named example-master, it will attempt to\r
 <link linkend="fast-forwards">fast-forward</link> to the commit given by example.com&#8217;s\r
 master branch.  In more detail:</simpara>\r
-</section>\r
-<section id="fetch-fast-forwards">\r
+</simplesect>\r
+<simplesect id="fetch-fast-forwards">\r
 <title>git fetch and fast-forwards</title>\r
 <simpara>In the previous example, when updating an existing branch, "git-fetch"\r
 checks to make sure that the most recent commit on the remote\r
@@ -1994,8 +1994,8 @@ described in the following section.  However, note that in the
 situation above this may mean losing the commits labeled "a" and "b",\r
 unless you&#8217;ve already created a reference of your own pointing to\r
 them.</simpara>\r
-</section>\r
-<section id="forcing-fetch">\r
+</simplesect>\r
+<simplesect id="forcing-fetch">\r
 <title>Forcing git-fetch to do non-fast-forward updates</title>\r
 <simpara>If git fetch fails because the new head of a branch is not a\r
 descendant of the old head, you may force the update with:</simpara>\r
@@ -2005,8 +2005,8 @@ flag to force updates of all the fetched branches, as in:</simpara>
 <literallayout>$ git fetch -f origin</literallayout>\r
 <simpara>Be aware that commits that the old version of example/master pointed at\r
 may be lost, as we saw in the previous section.</simpara>\r
-</section>\r
-<section id="remote-branch-configuration">\r
+</simplesect>\r
+<simplesect id="remote-branch-configuration">\r
 <title>Configuring remote branches</title>\r
 <simpara>We saw above that "origin" is just a shortcut to refer to the\r
 repository that you originally cloned from.  This information is\r
@@ -2042,15 +2042,15 @@ directly editing the file .git/config instead of using
 <ulink url="git-config.html">git-config(1)</ulink>.</simpara>\r
 <simpara>See <ulink url="git-config.html">git-config(1)</ulink> for more details on the configuration\r
 options mentioned above.</simpara>\r
-</section>\r
-</section>\r
-<section id="git-concepts">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="git-concepts">\r
 <title>Git concepts</title>\r
 <simpara>Git is built on a small number of simple but powerful ideas.  While it\r
 is possible to get things done without understanding them, you will find\r
 git much more intuitive if you do.</simpara>\r
 <simpara>We start with the most important, the  <link linkend="def_object_database">object database</link> and the <link linkend="def_index">index</link>.</simpara>\r
-<section id="the-object-database">\r
+<simplesect id="the-object-database">\r
 <title>The Object Database</title>\r
 <simpara>We already saw in <xref linkend="understanding-commits"/> that all commits are stored\r
 under a 40-digit "object name".  In fact, all the information needed to\r
@@ -2118,7 +2118,7 @@ A <link linkend="def_tag_object">"tag" object</link> symbolically identifies and
 </listitem>\r
 </itemizedlist>\r
 <simpara>The object types in some more detail:</simpara>\r
-<section id="commit-object">\r
+<simplesect id="commit-object">\r
 <title>Commit Object</title>\r
 <simpara>The "commit" object links a physical state of a tree with a description\r
 of how we got there and why.  Use the --pretty=raw option to\r
@@ -2183,8 +2183,8 @@ file data at changing paths suggests a rename.  (See, for example, the
 <simpara>A commit is usually created by <ulink url="git-commit.html">git-commit(1)</ulink>, which creates a\r
 commit whose parent is normally the current HEAD, and whose tree is\r
 taken from the content currently stored in the index.</simpara>\r
-</section>\r
-<section id="tree-object">\r
+</simplesect>\r
+<simplesect id="tree-object">\r
 <title>Tree Object</title>\r
 <simpara>The ever-versatile <ulink url="git-show.html">git-show(1)</ulink> command can also be used to\r
 examine tree objects, but <ulink url="git-ls-tree.html">git-ls-tree(1)</ulink> will give you more\r
@@ -2214,8 +2214,8 @@ identical object names.</simpara>
 entries.  See <xref linkend="submodules"/> for documentation.)</simpara>\r
 <simpara>Note that the files all have mode 644 or 755: git actually only pays\r
 attention to the executable bit.</simpara>\r
-</section>\r
-<section id="blob-object">\r
+</simplesect>\r
+<simplesect id="blob-object">\r
 <title>Blob Object</title>\r
 <simpara>You can use <ulink url="git-show.html">git-show(1)</ulink> to examine the contents of a blob; take,\r
 for example, the blob in the entry for "COPYING" from the tree above:</simpara>\r
@@ -2236,8 +2236,8 @@ renaming a file does not change the object that file is associated with.</simpar
 <ulink url="git-show.html">git-show(1)</ulink> with the &lt;revision&gt;:&lt;path&gt; syntax.  This can\r
 sometimes be useful for browsing the contents of a tree that is not\r
 currently checked out.</simpara>\r
-</section>\r
-<section id="trust">\r
+</simplesect>\r
+<simplesect id="trust">\r
 <title>Trust</title>\r
 <simpara>If you receive the SHA1 name of a blob from one source, and its contents\r
 from another (possibly untrusted) source, you can still trust that those\r
@@ -2260,8 +2260,8 @@ sending out a single email that tells the people the name (SHA1 hash)
 of the top commit, and digitally sign that email using something\r
 like GPG/PGP.</simpara>\r
 <simpara>To assist in this, git also provides the tag object&#8230;</simpara>\r
-</section>\r
-<section id="tag-object">\r
+</simplesect>\r
+<simplesect id="tag-object">\r
 <title>Tag Object</title>\r
 <simpara>A tag object contains an object, object type, tag name, the name of the\r
 person ("tagger") who created the tag, and a message, which may contain\r
@@ -2284,8 +2284,8 @@ nLE/L9aUXdWeTFPron96DLA=
 objects.  (Note that <ulink url="git-tag.html">git-tag(1)</ulink> can also be used to create\r
 "lightweight tags", which are not tag objects at all, but just simple\r
 references whose names begin with "refs/tags/").</simpara>\r
-</section>\r
-<section id="pack-files">\r
+</simplesect>\r
+<simplesect id="pack-files">\r
 <title>How git stores objects efficiently: pack files</title>\r
 <simpara>Newly created objects are initially created in a file named after the\r
 object&#8217;s SHA1 hash (stored in .git/objects).</simpara>\r
@@ -2323,8 +2323,8 @@ You can verify that the loose objects are gone by looking at the
 objects will work exactly as they did before.</simpara>\r
 <simpara>The <ulink url="git-gc.html">git-gc(1)</ulink> command performs packing, pruning, and more for\r
 you, so is normally the only high-level command you need.</simpara>\r
-</section>\r
-<section id="dangling-objects">\r
+</simplesect>\r
+<simplesect id="dangling-objects">\r
 <title>Dangling objects</title>\r
 <simpara>The <ulink url="git-fsck.html">git-fsck(1)</ulink> command will sometimes complain about dangling\r
 objects.  They are not a problem.</simpara>\r
@@ -2384,8 +2384,8 @@ Running it while somebody is actually changing the repository can cause
 confusing and scary messages, but it won&#8217;t actually do anything bad. In\r
 contrast, running "git prune" while somebody is actively changing the\r
 repository is a <emphasis role="strong">BAD</emphasis> idea).</simpara>\r
-</section>\r
-<section id="recovering-from-repository-corruption">\r
+</simplesect>\r
+<simplesect id="recovering-from-repository-corruption">\r
 <title>Recovering from repository corruption</title>\r
 <simpara>By design, git treats data trusted to it with caution.  However, even in\r
 the absence of bugs in git itself, it is still possible that hardware or\r
@@ -2464,9 +2464,9 @@ shot at reconstructing the contents of the in-between state 4b9458b.</simpara>
 <simpara>and just looked for the sha of the missing object (4b9458b..) in that\r
 whole thing. It&#8217;s up to you - git does <emphasis role="strong">have</emphasis> a lot of information, it is\r
 just missing one particular blob version.</simpara>\r
-</section>\r
-</section>\r
-<section id="the-index">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="the-index">\r
 <title>The index</title>\r
 <simpara>The index is a binary file (generally kept in .git/index) containing a\r
 sorted list of path names, each with permissions and the SHA1 of a blob\r
@@ -2524,9 +2524,9 @@ conflicts.</simpara>
 a tree which you are in the process of working on.</simpara>\r
 <simpara>If you blow the index away entirely, you generally haven&#8217;t lost any\r
 information as long as you have the name of the tree that it described.</simpara>\r
-</section>\r
-</section>\r
-<section id="submodules">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="submodules">\r
 <title>Submodules</title>\r
 <simpara>Large projects are often composed of smaller, self-contained modules.  For\r
 example, an embedded Linux distribution&#8217;s source tree would include every\r
@@ -2667,7 +2667,7 @@ $ git commit -m "Updated submodule a."
 $ git push</literallayout>\r
 <simpara>You have to run <literal>git submodule update</literal> after <literal>git pull</literal> if you want to update\r
 submodules, too.</simpara>\r
-<section id="_pitfalls_with_submodules">\r
+<simplesect id="_pitfalls_with_submodules">\r
 <title>Pitfalls with submodules</title>\r
 <simpara>Always publish the submodule change before publishing the change to the\r
 superproject that references it. If you forget to publish the submodule change,\r
@@ -2702,15 +2702,15 @@ $ cat a.txt
 module a</literallayout>\r
 <note><simpara>The changes are still visible in the submodule&#8217;s reflog.</simpara></note>\r
 <simpara>This is not the case if you did not commit your changes.</simpara>\r
-</section>\r
-</section>\r
-<section id="low-level-operations">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="low-level-operations">\r
 <title>Low-level git operations</title>\r
 <simpara>Many of the higher-level commands were originally implemented as shell\r
 scripts using a smaller core of low-level git commands.  These can still\r
 be useful when doing unusual things with git, or just as a way to\r
 understand its inner workings.</simpara>\r
-<section id="object-manipulation">\r
+<simplesect id="object-manipulation">\r
 <title>Object access and manipulation</title>\r
 <simpara>The <ulink url="git-cat-file.html">git-cat-file(1)</ulink> command can show the contents of any object,\r
 though the higher-level <ulink url="git-show.html">git-show(1)</ulink> is usually more useful.</simpara>\r
@@ -2722,8 +2722,8 @@ accessed by <ulink url="git-ls-tree.html">git-ls-tree(1)</ulink>.  Two trees can
 <simpara>A tag is created with <ulink url="git-mktag.html">git-mktag(1)</ulink>, and the signature can be\r
 verified by <ulink url="git-verify-tag.html">git-verify-tag(1)</ulink>, though it is normally simpler to\r
 use <ulink url="git-tag.html">git-tag(1)</ulink> for both.</simpara>\r
-</section>\r
-<section id="the-workflow">\r
+</simplesect>\r
+<simplesect id="the-workflow">\r
 <title>The Workflow</title>\r
 <simpara>High-level operations such as <ulink url="git-commit.html">git-commit(1)</ulink>,\r
 <ulink url="git-checkout.html">git-checkout(1)</ulink> and <ulink url="git-reset.html">git-reset(1)</ulink> work by moving data\r
@@ -2735,7 +2735,7 @@ work <emphasis role="strong">purely</emphasis> on the index file (showing the cu
 index), but most operations move data between the index file and either\r
 the database or the working directory. Thus there are four main\r
 combinations:</simpara>\r
-<section id="working-directory-to-index">\r
+<simplesect id="working-directory-to-index">\r
 <title>working directory &#8594; index</title>\r
 <simpara>The <ulink url="git-update-index.html">git-update-index(1)</ulink> command updates the index with\r
 information from the working directory.  You generally update the\r
@@ -2761,8 +2761,8 @@ it will only update the fields that are used to quickly test whether
 an object still matches its old backing store object.</simpara>\r
 <simpara>The previously introduced <ulink url="git-add.html">git-add(1)</ulink> is just a wrapper for\r
 <ulink url="git-update-index.html">git-update-index(1)</ulink>.</simpara>\r
-</section>\r
-<section id="index-to-object-database">\r
+</simplesect>\r
+<simplesect id="index-to-object-database">\r
 <title>index &#8594; object database</title>\r
 <simpara>You write your current index file to a "tree" object with the program</simpara>\r
 <literallayout>$ git write-tree</literallayout>\r
@@ -2771,8 +2771,8 @@ current index into the set of tree objects that describe that state,
 and it will return the name of the resulting top-level tree. You can\r
 use that tree to re-generate the index at any time by going in the\r
 other direction:</simpara>\r
-</section>\r
-<section id="object-database-to-index">\r
+</simplesect>\r
+<simplesect id="object-database-to-index">\r
 <title>object database &#8594; index</title>\r
 <simpara>You read a "tree" file from the object database, and use that to\r
 populate (and overwrite&#8212;don&#8217;t do this if your index contains any\r
@@ -2782,8 +2782,8 @@ index.  Normal operation is just</simpara>
 <simpara>and your index file will now be equivalent to the tree that you saved\r
 earlier. However, that is only your <emphasis>index</emphasis> file: your working\r
 directory contents have not been modified.</simpara>\r
-</section>\r
-<section id="index-to-working-directory">\r
+</simplesect>\r
+<simplesect id="index-to-working-directory">\r
 <title>index &#8594; working directory</title>\r
 <simpara>You update your working directory from the index by "checking out"\r
 files. This is not a very common operation, since normally you&#8217;d just\r
@@ -2802,8 +2802,8 @@ need to use the "-f" flag (<emphasis>before</emphasis> the "-a" flag or the file
 <emphasis>force</emphasis> the checkout.</simpara>\r
 <simpara>Finally, there are a few odds and ends which are not purely moving\r
 from one representation to the other:</simpara>\r
-</section>\r
-<section id="tying-it-all-together">\r
+</simplesect>\r
+<simplesect id="tying-it-all-together">\r
 <title>Tying it all together</title>\r
 <simpara>To commit a tree you have instantiated with "git write-tree", you&#8217;d\r
 create a "commit" object that refers to that tree and the history\r
@@ -2861,9 +2861,9 @@ various pieces fit together.</simpara>
                     |  Working  |\r
                     | Directory |\r
                     +-----------+</literallayout>\r
-</section>\r
-</section>\r
-<section id="examining-the-data">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="examining-the-data">\r
 <title>Examining the data</title>\r
 <simpara>You can examine the data represented in the object database and the\r
 index with various helper tools. For every object, you can use\r
@@ -2883,8 +2883,8 @@ follow the convention of having the top commit name in <literal>.git/HEAD</liter
 you can do</simpara>\r
 <literallayout>$ git cat-file commit HEAD</literallayout>\r
 <simpara>to see what the top commit was.</simpara>\r
-</section>\r
-<section id="merging-multiple-trees">\r
+</simplesect>\r
+<simplesect id="merging-multiple-trees">\r
 <title>Merging multiple trees</title>\r
 <simpara>Git helps you do a three-way merge, which you can expand to n-way by\r
 repeating the merge procedure arbitrary times until you finally\r
@@ -2916,8 +2916,8 @@ you have in your current index anyway).</simpara>
 <simpara>which will do all trivial merge operations for you directly in the\r
 index file, and you can just write the result out with\r
 <literal>git write-tree</literal>.</simpara>\r
-</section>\r
-<section id="merging-multiple-trees-2">\r
+</simplesect>\r
+<simplesect id="merging-multiple-trees-2">\r
 <title>Merging multiple trees, continued</title>\r
 <simpara>Sadly, many merges aren&#8217;t trivial. If there are files that have\r
 been added, moved or removed, or if both branches have modified the\r
@@ -2966,13 +2966,13 @@ for this.  There is a <literal>git-merge-index</literal> program that extracts t
 stages to temporary files and calls a "merge" script on it:</simpara>\r
 <literallayout>$ git merge-index git-merge-one-file hello.c</literallayout>\r
 <simpara>and that is what higher level <literal>git-merge -s resolve</literal> is implemented with.</simpara>\r
-</section>\r
-</section>\r
-<section id="hacking-git">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="hacking-git">\r
 <title>Hacking git</title>\r
 <simpara>This chapter covers internal details of the git implementation which\r
 probably only git developers need to understand.</simpara>\r
-<section id="object-details">\r
+<simplesect id="object-details">\r
 <title>Object storage format</title>\r
 <simpara>All objects have a statically determined "type" which identifies the\r
 format of the object (i.e. how it is used, and how it can refer to other\r
@@ -2998,8 +2998,8 @@ connectivity to other objects verified. This is generally done with
 the <literal>git-fsck</literal> program, which generates a full dependency graph\r
 of all objects, and verifies their internal consistency (in addition\r
 to just verifying their superficial consistency through the hash).</simpara>\r
-</section>\r
-<section id="birdview-on-the-source-code">\r
+</simplesect>\r
+<simplesect id="birdview-on-the-source-code">\r
 <title>A birds-eye view of Git&#8217;s source code</title>\r
 <simpara>It is not always easy for new developers to find their way through Git&#8217;s\r
 source code.  This section gives you a little guidance to show where to\r
@@ -3171,9 +3171,9 @@ builtin:</simpara>
 <literallayout>$ git log --no-merges --diff-filter=A builtin-*.c</literallayout>\r
 <simpara>You see, Git is actually the best tool to find out about the source of Git\r
 itself!</simpara>\r
-</section>\r
-</section>\r
-<section id="glossary">\r
+</simplesect>\r
+</simplesect>\r
+<simplesect id="glossary">\r
 <title>GIT Glossary</title>\r
 <variablelist>\r
 <varlistentry>\r
@@ -4137,12 +4137,12 @@ This commit is referred to as a "merge commit", or sometimes just a
 </listitem>\r
 </varlistentry>\r
 </variablelist>\r
-</section>\r
+</simplesect>\r
 <appendix id="git-quick-start">\r
 <title>Git Quick Reference</title>\r
 <simpara>This is a quick summary of the major commands; the previous chapters\r
 explain how these work in more detail.</simpara>\r
-<section id="quick-creating-a-new-repository">\r
+<simplesect id="quick-creating-a-new-repository">\r
 <title>Creating a new repository</title>\r
 <simpara>From a tarball:</simpara>\r
 <literallayout>$ tar xzf project.tar.gz\r
@@ -4154,8 +4154,8 @@ $ git commit</literallayout>
 <simpara>From a remote repository:</simpara>\r
 <literallayout>$ git clone git://example.com/pub/project.git\r
 $ cd project</literallayout>\r
-</section>\r
-<section id="managing-branches">\r
+</simplesect>\r
+<simplesect id="managing-branches">\r
 <title>Managing branches</title>\r
 <literallayout>$ git branch         # list all local branches in this repo\r
 $ git checkout test  # switch working directory to branch "test"\r
@@ -4194,8 +4194,8 @@ $ git remote show example       # get details
     ...\r
 $ git fetch example             # update branches from example\r
 $ git branch -r                 # list all remote branches</literallayout>\r
-</section>\r
-<section id="exploring-history">\r
+</simplesect>\r
+<simplesect id="exploring-history">\r
 <title>Exploring history</title>\r
 <literallayout>$ gitk                      # visualize and browse history\r
 $ git log                   # list all commits\r
@@ -4222,8 +4222,8 @@ Bisecting: 675 revisions left to test after this
 $ git bisect good               # if this revision is good, or\r
 $ git bisect bad                # if this revision is bad.\r
                                 # repeat until done.</literallayout>\r
-</section>\r
-<section id="making-changes">\r
+</simplesect>\r
+<simplesect id="making-changes">\r
 <title>Making changes</title>\r
 <simpara>Make sure git knows who to blame:</simpara>\r
 <literallayout>$ cat &gt;&gt;~/.gitconfig &lt;&lt;\EOF\r
@@ -4240,15 +4240,15 @@ $ git commit</literallayout>
 <simpara>Or, prepare and create the commit in one step:</simpara>\r
 <literallayout>$ git commit d.txt # use latest content only of d.txt\r
 $ git commit -a    # use latest content of all tracked files</literallayout>\r
-</section>\r
-<section id="merging">\r
+</simplesect>\r
+<simplesect id="merging">\r
 <title>Merging</title>\r
 <literallayout>$ git merge test   # merge branch "test" into the current branch\r
 $ git pull git://example.com/project.git master\r
                    # fetch and merge in remote branch\r
 $ git pull . test  # equivalent to git merge test</literallayout>\r
-</section>\r
-<section id="sharing-your-changes">\r
+</simplesect>\r
+<simplesect id="sharing-your-changes">\r
 <title>Sharing your changes</title>\r
 <simpara>Importing or exporting patches:</simpara>\r
 <literallayout>$ git format-patch origin..HEAD # format a patch for each commit\r
@@ -4268,14 +4268,14 @@ branch with your commits:</simpara>
 <simpara>Shortcut version for a frequently used remote repository:</simpara>\r
 <literallayout>$ git remote add example ssh://example.com/project.git\r
 $ git push example test</literallayout>\r
-</section>\r
-<section id="repository-maintenance">\r
+</simplesect>\r
+<simplesect id="repository-maintenance">\r
 <title>Repository maintenance</title>\r
 <simpara>Check for corruption:</simpara>\r
 <literallayout>$ git fsck</literallayout>\r
 <simpara>Recompress, remove unused cruft:</simpara>\r
 <literallayout>$ git gc</literallayout>\r
-</section>\r
+</simplesect>\r
 </appendix>\r
 <appendix id="todo">\r
 <title>Notes and todo list for this manual</title>\r