From 6fb124cd538ba3d8d7c5da9bb979b3fd0e1b2925 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 13 Jun 2008 10:04:01 +0000 Subject: [PATCH] Autogenerated HTML docs for v1.5.6-rc2-45-gdc92c --- RelNotes-1.5.6.txt | 2 +- git-diff-tree.html | 26 +++++++++++++++++++++++++- git-log.html | 26 +++++++++++++++++++++++++- git-pull.html | 13 ++++++++++--- git-pull.txt | 3 ++- git-remote.html | 11 +++++------ git-remote.txt | 9 ++++----- git-rev-list.html | 26 +++++++++++++++++++++++++- git-show.html | 26 +++++++++++++++++++++++++- git-whatchanged.html | 26 +++++++++++++++++++++++++- gittutorial.html | 4 ++-- gittutorial.txt | 2 +- pretty-formats.txt | 22 ++++++++++++++++++++++ user-manual.html | 19 +++++++++---------- user-manual.txt | 15 +++++++-------- 15 files changed, 188 insertions(+), 42 deletions(-) diff --git a/RelNotes-1.5.6.txt b/RelNotes-1.5.6.txt index a79e4b939..ac4881e19 100644 --- a/RelNotes-1.5.6.txt +++ b/RelNotes-1.5.6.txt @@ -70,7 +70,7 @@ Updates since v1.5.5 * "git init --bare" is a synonym for "git --bare init" now. -* "git gc --auto" honors a new pre-aut-gc hook to temporarily disable it. +* "git gc --auto" honors a new pre-auto-gc hook to temporarily disable it. * "git log --pretty=tformat:" gives a LF after each entry, instead of giving a LF between each pair of entries which is how diff --git a/git-diff-tree.html b/git-diff-tree.html index 0880d5acf..f1875d3b3 100644 --- a/git-diff-tree.html +++ b/git-diff-tree.html @@ -1234,6 +1234,30 @@ The title was >>t4119: test autocomputing -p<n> for traditional diff +
  • +

    +tformat: +

    +

    The tformat: format works exactly like format:, except that it +provides "terminator" semantics instead of "separator" semantics. In +other words, each commit has the message terminator character (usually a +newline) appended, rather than a separator placed between entries. +This means that the final entry of a single-line format will be properly +terminated with a new line, just as the "oneline" format does. +For example:

    +
    +
    +
    $ git log -2 --pretty=format:%h 4da45bef \
+  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
+4da45be
+7134973 -- NO NEWLINE
+
+$ git log -2 --pretty=tformat:%h 4da45bef \
+  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
+4da45be
+7134973
    +
    +

    • Limiting Output

    @@ -1773,7 +1797,7 @@ the pathname, but if that is NUL, the record will show two paths.

    diff --git a/git-log.html b/git-log.html index 4154c626e..d5e83b836 100644 --- a/git-log.html +++ b/git-log.html @@ -1611,6 +1611,30 @@ The title was >>t4119: test autocomputing -p<n> for traditional diff +
  • +

    +tformat: +

    +

    The tformat: format works exactly like format:, except that it +provides "terminator" semantics instead of "separator" semantics. In +other words, each commit has the message terminator character (usually a +newline) appended, rather than a separator placed between entries. +This means that the final entry of a single-line format will be properly +terminated with a new line, just as the "oneline" format does. +For example:

    +
    +
    +
    $ git log -2 --pretty=format:%h 4da45bef \
+  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
+4da45be
+7134973 -- NO NEWLINE
+
+$ git log -2 --pretty=tformat:%h 4da45bef \
+  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
+4da45be
+7134973
    +
    +

    • Generating patches with -p

    @@ -1940,7 +1964,7 @@ reversible operation.

    diff --git a/git-pull.html b/git-pull.html index 77107a4a3..8b9e1ec17 100644 --- a/git-pull.html +++ b/git-pull.html @@ -429,10 +429,17 @@ when merging local branches into the current branch.

    for branch <name>, set configuration branch.<name>.rebase to true.

    -

    NOTE: This is a potentially _dangerous_ mode of operation. +

    + + + +
    +
    Note
    +    		This is a potentially _dangerous_ mode of operation. It rewrites history, which does not bode well when you published that history already. Do not use this option -unless you have read git-rebase(1) carefully.

    +unless you have read git-rebase(1) carefully.
    +
    --no-rebase @@ -1095,7 +1102,7 @@ Junio C Hamano and the git-list <git@vger.kernel.org>.

    diff --git a/git-pull.txt b/git-pull.txt index 5f55f6494..d0f1595f7 100644 --- a/git-pull.txt +++ b/git-pull.txt @@ -38,7 +38,8 @@ include::merge-options.txt[] for branch ``, set configuration `branch..rebase` to `true`. + -*NOTE:* This is a potentially _dangerous_ mode of operation. +[NOTE] +This is a potentially _dangerous_ mode of operation. It rewrites history, which does not bode well when you published that history already. Do *not* use this option unless you have read linkgit:git-rebase[1] carefully. diff --git a/git-remote.html b/git-remote.html index 845cd5605..1df4bbf72 100644 --- a/git-remote.html +++ b/git-remote.html @@ -276,8 +276,8 @@ git-remote(1) Manual Page
    git-remote [-v | --verbose] git-remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url> git-remote rm <name> -git-remote show <name> -git-remote prune <name> +git-remote show [-n] <name> +git-remote prune [-n | --dry-run] <name> git-remote update [group]

    DESCRIPTION

    @@ -359,9 +359,8 @@ These stale branches have already been removed from the remote repository referenced by <name>, but are still locally available in "remotes/<name>".

    -

    With -n option, the remote heads are not confirmed first with git -ls-remote <name>; cached information is used instead. Use with -caution.

    +

    With --dry-run option, report what branches will be pruned, but do no +actually prune them.

    update @@ -446,7 +445,7 @@ $ git merge origin diff --git a/git-remote.txt b/git-remote.txt index 782b0554c..345943a26 100644 --- a/git-remote.txt +++ b/git-remote.txt @@ -12,8 +12,8 @@ SYNOPSIS 'git-remote' [-v | --verbose] 'git-remote' add [-t ] [-m ] [-f] [--mirror] 'git-remote' rm -'git-remote' show -'git-remote' prune +'git-remote' show [-n] +'git-remote' prune [-n | --dry-run] 'git-remote' update [group] DESCRIPTION @@ -80,9 +80,8 @@ These stale branches have already been removed from the remote repository referenced by , but are still locally available in "remotes/". + -With `-n` option, the remote heads are not confirmed first with `git -ls-remote `; cached information is used instead. Use with -caution. +With `--dry-run` option, report what branches will be pruned, but do no +actually prune them. 'update':: diff --git a/git-rev-list.html b/git-rev-list.html index 66afe2b69..b26b4e34b 100644 --- a/git-rev-list.html +++ b/git-rev-list.html @@ -1238,6 +1238,30 @@ The title was >>t4119: test autocomputing -p<n> for traditional diff +
  • +

    +tformat: +

    +

    The tformat: format works exactly like format:, except that it +provides "terminator" semantics instead of "separator" semantics. In +other words, each commit has the message terminator character (usually a +newline) appended, rather than a separator placed between entries. +This means that the final entry of a single-line format will be properly +terminated with a new line, just as the "oneline" format does. +For example:

    +
    +
    +
    $ git log -2 --pretty=format:%h 4da45bef \
+  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
+4da45be
+7134973 -- NO NEWLINE
+
+$ git log -2 --pretty=tformat:%h 4da45bef \
+  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
+4da45be
+7134973
    +
    +

    • Author

    @@ -1255,7 +1279,7 @@ and the git-list <git@vger.kernel.org>.

    diff --git a/git-show.html b/git-show.html index de346db37..d6c44a5ed 100644 --- a/git-show.html +++ b/git-show.html @@ -634,6 +634,30 @@ The title was >>t4119: test autocomputing -p<n> for traditional diff +
  • +

    +tformat: +

    +

    The tformat: format works exactly like format:, except that it +provides "terminator" semantics instead of "separator" semantics. In +other words, each commit has the message terminator character (usually a +newline) appended, rather than a separator placed between entries. +This means that the final entry of a single-line format will be properly +terminated with a new line, just as the "oneline" format does. +For example:

    +
    +
    +
    $ git log -2 --pretty=format:%h 4da45bef \
+  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
+4da45be
+7134973 -- NO NEWLINE
+
+$ git log -2 --pretty=tformat:%h 4da45bef \
+  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
+4da45be
+7134973
    +
    +

    • EXAMPLES

    @@ -768,7 +792,7 @@ Johannes Schindelin <Johannes.Schindelin@gmx.de>.

    diff --git a/git-whatchanged.html b/git-whatchanged.html index aaa6620e4..7d0836a20 100644 --- a/git-whatchanged.html +++ b/git-whatchanged.html @@ -666,6 +666,30 @@ The title was >>t4119: test autocomputing -p<n> for traditional diff +
  • +

    +tformat: +

    +

    The tformat: format works exactly like format:, except that it +provides "terminator" semantics instead of "separator" semantics. In +other words, each commit has the message terminator character (usually a +newline) appended, rather than a separator placed between entries. +This means that the final entry of a single-line format will be properly +terminated with a new line, just as the "oneline" format does. +For example:

    +
    +
    +
    $ git log -2 --pretty=format:%h 4da45bef \
+  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
+4da45be
+7134973 -- NO NEWLINE
+
+$ git log -2 --pretty=tformat:%h 4da45bef \
+  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
+4da45be
+7134973
    +
    +

    • Examples

    @@ -707,7 +731,7 @@ Junio C Hamano <junkio@cox.net>

    diff --git a/gittutorial.html b/gittutorial.html index 852fcdfdc..7bc31e321 100644 --- a/gittutorial.html +++ b/gittutorial.html @@ -363,7 +363,7 @@ newly modified content to the index. Finally, commit your changes with:

    $ git commit
    -

    This will again prompt your for a message describing the change, and then +

    This will again prompt you for a message describing the change, and then record a new version of the project.

    Alternatively, instead of running git add beforehand, you can use

    @@ -811,7 +811,7 @@ digressions that may be interesting at this point are:

    diff --git a/gittutorial.txt b/gittutorial.txt index 9563a632e..d465aab64 100644 --- a/gittutorial.txt +++ b/gittutorial.txt @@ -114,7 +114,7 @@ newly modified content to the index. Finally, commit your changes with: $ git commit ------------------------------------------------ -This will again prompt your for a message describing the change, and then +This will again prompt you for a message describing the change, and then record a new version of the project. Alternatively, instead of running `git add` beforehand, you can use diff --git a/pretty-formats.txt b/pretty-formats.txt index e8bea3e18..ec3755579 100644 --- a/pretty-formats.txt +++ b/pretty-formats.txt @@ -124,3 +124,25 @@ The placeholders are: - '%m': left, right or boundary mark - '%n': newline - '%x00': print a byte from a hex code + +* 'tformat:' ++ +The 'tformat:' format works exactly like 'format:', except that it +provides "terminator" semantics instead of "separator" semantics. In +other words, each commit has the message terminator character (usually a +newline) appended, rather than a separator placed between entries. +This means that the final entry of a single-line format will be properly +terminated with a new line, just as the "oneline" format does. +For example: ++ +--------------------- +$ git log -2 --pretty=format:%h 4da45bef \ + | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' +4da45be +7134973 -- NO NEWLINE + +$ git log -2 --pretty=tformat:%h 4da45bef \ + | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' +4da45be +7134973 +--------------------- diff --git a/user-manual.html b/user-manual.html index 67ddd6592..0116b844e 100644 --- a/user-manual.html +++ b/user-manual.html @@ -1,4 +1,4 @@ -Git User's Manual (for version 1.5.3 or newer)

    Git User's Manual (for version 1.5.3 or newer)

    Table of Contents

    Preface
    1. Repositories and Branches
    How to get a git repository
    How to check out a different version of a project
    Understanding History: Commits
    Understanding history: commits, parents, and reachability
    Understanding history: History diagrams
    Understanding history: What is a branch?
    Manipulating branches
    Examining an old version without creating a new branch
    Examining branches from a remote repository
    Naming branches, tags, and other references
    Updating a repository with git fetch
    Fetching branches from other repositories
    2. Exploring git history
    How to use bisect to find a regression
    Naming commits
    Creating tags
    Browsing revisions
    Generating diffs
    Viewing old file versions
    Examples
    Counting the number of commits on a branch
    Check whether two branches point at the same history
    Find first tagged version including a given fix
    Showing commits unique to a given branch
    Creating a changelog and tarball for a software release
    Finding commits referencing a file with given content
    3. Developing with git
    Telling git your name
    Creating a new repository
    How to make a commit
    Creating good commit messages
    Ignoring files
    How to merge
    Resolving a merge
    Getting conflict-resolution help during a merge
    Undoing a merge
    Fast-forward merges
    Fixing mistakes
    Fixing a mistake with a new commit
    Fixing a mistake by rewriting history
    Checking out an old version of a file
    Temporarily setting aside work in progress
    Ensuring good performance
    Ensuring reliability
    Checking the repository for corruption
    Recovering lost changes
    4. Sharing development with others
    Getting updates with git pull
    Submitting patches to a project
    Importing patches to a project
    Public git repositories
    Setting up a public repository
    Exporting a git repository via the git protocol
    Exporting a git repository via http
    Pushing changes to a public repository
    What to do when a push fails
    Setting up a shared repository
    Allowing web browsing of a repository
    Examples
    Maintaining topic branches for a Linux subsystem maintainer
    5. Rewriting history and maintaining patch series
    Creating the perfect patch series
    Keeping a patch series up to date using git-rebase
    Rewriting a single commit
    Reordering or selecting from a patch series
    Other tools
    Problems with rewriting history
    Why bisecting merge commits can be harder than bisecting linear history
    6. Advanced branch management
    Fetching individual branches
    git fetch and fast-forwards
    Forcing git fetch to do non-fast-forward updates
    Configuring remote branches
    7. Git concepts
    The Object Database
    Commit Object
    Tree Object
    Blob Object
    Trust
    Tag Object
    How git stores objects efficiently: pack files
    Dangling objects
    Recovering from repository corruption
    The index
    8. Submodules
    Pitfalls with submodules
    9. Low-level git operations
    Object access and manipulation
    The Workflow
    working directory -> index
    index -> object database
    object database -> index
    index -> working directory
    Tying it all together
    Examining the data
    Merging multiple trees
    Merging multiple trees, continued
    10. Hacking git
    Object storage format
    A birds-eye view of Git's source code
    11. GIT Glossary
    A. Git Quick Reference
    Creating a new repository
    Managing branches
    Exploring history
    Making changes
    Merging
    Sharing your changes
    Repository maintenance
    B. Notes and todo list for this manual

    Preface

    Git is a fast distributed revision control system.

    This manual is designed to be readable by someone with basic UNIX +Git User's Manual (for version 1.5.3 or newer)

    Git User's Manual (for version 1.5.3 or newer)

    Table of Contents

    Preface
    1. Repositories and Branches
    How to get a git repository
    How to check out a different version of a project
    Understanding History: Commits
    Understanding history: commits, parents, and reachability
    Understanding history: History diagrams
    Understanding history: What is a branch?
    Manipulating branches
    Examining an old version without creating a new branch
    Examining branches from a remote repository
    Naming branches, tags, and other references
    Updating a repository with git fetch
    Fetching branches from other repositories
    2. Exploring git history
    How to use bisect to find a regression
    Naming commits
    Creating tags
    Browsing revisions
    Generating diffs
    Viewing old file versions
    Examples
    Counting the number of commits on a branch
    Check whether two branches point at the same history
    Find first tagged version including a given fix
    Showing commits unique to a given branch
    Creating a changelog and tarball for a software release
    Finding commits referencing a file with given content
    3. Developing with git
    Telling git your name
    Creating a new repository
    How to make a commit
    Creating good commit messages
    Ignoring files
    How to merge
    Resolving a merge
    Getting conflict-resolution help during a merge
    Undoing a merge
    Fast-forward merges
    Fixing mistakes
    Fixing a mistake with a new commit
    Fixing a mistake by rewriting history
    Checking out an old version of a file
    Temporarily setting aside work in progress
    Ensuring good performance
    Ensuring reliability
    Checking the repository for corruption
    Recovering lost changes
    4. Sharing development with others
    Getting updates with git pull
    Submitting patches to a project
    Importing patches to a project
    Public git repositories
    Setting up a public repository
    Exporting a git repository via the git protocol
    Exporting a git repository via http
    Pushing changes to a public repository
    What to do when a push fails
    Setting up a shared repository
    Allowing web browsing of a repository
    Examples
    Maintaining topic branches for a Linux subsystem maintainer
    5. Rewriting history and maintaining patch series
    Creating the perfect patch series
    Keeping a patch series up to date using git-rebase
    Rewriting a single commit
    Reordering or selecting from a patch series
    Other tools
    Problems with rewriting history
    Why bisecting merge commits can be harder than bisecting linear history
    6. Advanced branch management
    Fetching individual branches
    git fetch and fast-forwards
    Forcing git fetch to do non-fast-forward updates
    Configuring remote branches
    7. Git concepts
    The Object Database
    Commit Object
    Tree Object
    Blob Object
    Trust
    Tag Object
    How git stores objects efficiently: pack files
    Dangling objects
    Recovering from repository corruption
    The index
    8. Submodules
    Pitfalls with submodules
    9. Low-level git operations
    Object access and manipulation
    The Workflow
    working directory -> index
    index -> object database
    object database -> index
    index -> working directory
    Tying it all together
    Examining the data
    Merging multiple trees
    Merging multiple trees, continued
    10. Hacking git
    Object storage format
    A birds-eye view of Git's source code
    11. GIT Glossary
    A. Git Quick Reference
    Creating a new repository
    Managing branches
    Exploring history
    Making changes
    Merging
    Sharing your changes
    Repository maintenance
    B. Notes and todo list for this manual

    Preface

    Git is a fast distributed revision control system.

    This manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of git.

    Chapter 1, Repositories and Branches and Chapter 2, Exploring git history 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 @@ -508,13 +508,12 @@ conflict will have two parents instead of the usual one: one parent will be HEAD, the tip of the current branch; the other will be the tip of the other branch, which is stored temporarily in MERGE_HEAD.

    During the merge, the index holds three versions of each file. Each of these three "file stages" represents a different version of the file:

    $ git show :1:file.txt  # the file in a common ancestor of both branches
    -$ git show :2:file.txt  # the version from HEAD, but including any
    -                        # nonconflicting changes from MERGE_HEAD
    -$ git show :3:file.txt  # the version from MERGE_HEAD, but including any
    -                        # nonconflicting changes from HEAD.

    Since the stage 2 and stage 3 versions have already been updated with -nonconflicting changes, the only remaining differences between them are -the important ones; thus git-diff(1) can use the information in -the index to show only those conflicts.

    The diff above shows the differences between the working-tree version of +$ git show :2:file.txt  # the version from HEAD.
    +$ git show :3:file.txt  # the version from MERGE_HEAD.

    When you ask git-diff(1) to show the conflicts, it runs a +three-way diff between the conflicted merge results in the work tree with +stages 2 and 3 to show only hunks whose contents come from both sides, +mixed (in other words, when a hunk's merge results come only from stage 2, +that part is not conflicting and is not shown. Same for stage 3).

    The diff above shows the differences between the working-tree version of file.txt and the stage 2 and stage 3 versions. So instead of preceding each line by a single "+" or "-", it now uses two columns: the first column is used for differences between the first parent and the working @@ -1442,7 +1441,7 @@ column in the git-ls-files(1) outp number, and will take on values other than 0 for files with merge conflicts.

    The index is thus a sort of temporary staging area, which is filled with a tree which you are in the process of working on.

    If you blow the index away entirely, you generally haven't lost any -information as long as you have the name of the tree that it described.

    Chapter 8. Submodules

    Table of Contents

    Pitfalls with submodules

    Large projects are often composed of smaller, self-contained modules. For +information as long as you have the name of the tree that it described.

    Chapter 8. Submodules

    Table of Contents

    Pitfalls with submodules

    Large projects are often composed of smaller, self-contained modules. For example, an embedded Linux distribution's source tree would include every piece of software in the distribution with some local modifications; a movie player might need to build against a specific, known-working version of a @@ -1536,7 +1535,7 @@ index d266b98..261dfac 160000
    $ git add a
    $ git commit -m "Updated submodule a."
    $ git push

    You have to run git submodule update after git pull if you want to update -submodules, too.

    Pitfalls with submodules

    Always publish the submodule change before publishing the change to the +submodules, too.

    Pitfalls with submodules

    Always publish the submodule change before publishing the change to the superproject that references it. If you forget to publish the submodule change, others won't be able to clone the repository:

    $ cd ~/git/super/a
    $ echo i added another line to this file >> a.txt
    diff --git a/user-manual.txt b/user-manual.txt index bfde507e0..64a820bf6 100644 --- a/user-manual.txt +++ b/user-manual.txt @@ -1254,16 +1254,15 @@ these three "file stages" represents a different version of the file: ------------------------------------------------- $ git show :1:file.txt # the file in a common ancestor of both branches -$ git show :2:file.txt # the version from HEAD, but including any - # nonconflicting changes from MERGE_HEAD -$ git show :3:file.txt # the version from MERGE_HEAD, but including any - # nonconflicting changes from HEAD. +$ git show :2:file.txt # the version from HEAD. +$ git show :3:file.txt # the version from MERGE_HEAD. ------------------------------------------------- -Since the stage 2 and stage 3 versions have already been updated with -nonconflicting changes, the only remaining differences between them are -the important ones; thus linkgit:git-diff[1] can use the information in -the index to show only those conflicts. +When you ask linkgit:git-diff[1] to show the conflicts, it runs a +three-way diff between the conflicted merge results in the work tree with +stages 2 and 3 to show only hunks whose contents come from both sides, +mixed (in other words, when a hunk's merge results come only from stage 2, +that part is not conflicting and is not shown. Same for stage 3). The diff above shows the differences between the working-tree version of file.txt and the stage 2 and stage 3 versions. So instead of preceding -- 2.26.2