From edd2b0a4fa552d711bcf7561dead9c6c87146701 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Mon, 15 Jan 2007 06:12:45 +0000 Subject: [PATCH] Autogenerated HTML docs for v1.5.0-rc1-g5fe3 --- config.txt | 7 +++++ core-tutorial.html | 67 +++++++++++--------------------------------- core-tutorial.txt | 51 +++++++++------------------------ everyday.html | 5 ++-- everyday.txt | 3 +- git-describe.html | 40 +++++++++++++++++++++++++- git-describe.txt | 30 ++++++++++++++++++++ git-log.html | 4 +-- git-log.txt | 2 +- git-pull.html | 5 ++-- git-pull.txt | 3 +- git-repo-config.html | 14 ++++++++- git-rerere.html | 12 ++++---- git-rerere.txt | 10 +++---- git-reset.html | 6 +--- git-reset.txt | 4 --- tutorial.html | 22 +++++++-------- tutorial.txt | 20 ++++++------- 18 files changed, 161 insertions(+), 144 deletions(-) diff --git a/config.txt b/config.txt index f7dba8977..faa17ba84 100644 --- a/config.txt +++ b/config.txt @@ -321,6 +321,13 @@ merge.summary:: Whether to include summaries of merged commits in newly created merge commit messages. False by default. +merge.verbosity:: + Controls the amount of output shown by the recursive merge + strategy. Level 0 outputs nothing except a final error + message if conflicts were detected. Level 1 outputs only + conflicts, 2 outputs conflicts and file changes. Level 5 and + above outputs debugging information. The default is level 2. + pack.window:: The size of the window used by gitlink:git-pack-objects[1] when no window size is given on the command line. Defaults to 10. diff --git a/core-tutorial.html b/core-tutorial.html index dd84bf099..1d4cba40a 100644 --- a/core-tutorial.html +++ b/core-tutorial.html @@ -1129,17 +1129,12 @@ of it as it can automatically (which in this case is just merge the example< file, which had no differences in the mybranch branch), and say:

-
        Trying really trivial in-index merge...
-        fatal: Merge requires file-level merging
-        Nope.
-        ...
-        Auto-merging hello
+
        Auto-merging hello
         CONFLICT (content): Merge conflict in hello
         Automatic merge failed; fix up by hand
-

which is way too verbose, but it basically tells you that it failed the -really trivial merge ("Simple merge") and did an "Automatic merge" -instead, but that too failed due to conflicts in hello.

+

It tells you that it did an "Automatic merge", which +failed due to conflicts in hello.

Not to worry. It left the (trivial) conflict in hello in the same form you should already be well used to if you've ever used CVS, so let's just open hello in our editor (whatever that may be), and fix it up somehow. @@ -1357,37 +1352,15 @@ course, you will pay the price of more disk usage to hold multiple working trees, but disk space is cheap these days. -

- - - -
-
Note
-		You could even pull from your own repository by -giving . as <remote-repository> parameter to git pull. This -is useful when you want to merge a local branch (or more, if you -are making an Octopus) into the current branch.
-

It is likely that you will be pulling from the same remote repository from time to time. As a short hand, you can store -the remote repository URL in a file under .git/remotes/ -directory, like this:

-
-
-
$ mkdir -p .git/remotes/
-$ cat >.git/remotes/linus <<\EOF
-URL: http://www.kernel.org/pub/scm/git/git.git/
-EOF
-
-

and use the filename to git pull instead of the full URL. -The URL specified in such file can even be a prefix -of a full URL, like this:

+the remote repository URL in the local repository's config file +like this:

-
$ cat >.git/remotes/jgarzik <<\EOF
-URL: http://www.kernel.org/pub/scm/linux/git/jgarzik/
-EOF
+
$ git repo-config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
+

and use the "linus" keyword with git pull instead of the full URL.

Examples.

  1. @@ -1400,11 +1373,6 @@ EOF git pull linus tag v0.99.1

    2. -
  2. -

    -git pull jgarzik/netdev-2.6.git/ e100 -

    -

the above are equivalent to:

    @@ -1418,11 +1386,6 @@ EOF git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1

    -
  1. -

    -git pull http://www.kernel.org/pub/…/jgarzik/netdev-2.6.git e100 -

    -

How does the merge work?

@@ -1812,7 +1775,8 @@ on that project and has an own "public repository" goes like this:

Prepare your work repository, by git clone the public repository of the "project lead". The URL used for the - initial cloning is stored in .git/remotes/origin. + initial cloning is stored in the remote.origin.url + configuration variable.

  • @@ -1872,7 +1836,8 @@ like this:

    Prepare your work repository, by git clone the public repository of the "project lead" (or a "subsystem maintainer", if you work on a subsystem). The URL used for - the initial cloning is stored in .git/remotes/origin. + the initial cloning is stored in the remote.origin.url + configuration variable.

  • @@ -1885,7 +1850,7 @@ Do your work in your repository on master branch. Run git fetch origin from the public repository of your upstream every once in a while. This does only the first half of git pull but does not merge. The head of the - public repository is stored in .git/refs/heads/origin. + public repository is stored in .git/refs/remotes/origin/master.

  • @@ -1973,11 +1938,11 @@ branch before these two merges by resetting it to master~2:

    You can make sure git show-branch matches the state before those two git merge you just did. Then, instead of running -two git merge commands in a row, you would pull these two +two git merge commands in a row, you would merge these two branch heads (this is known as making an Octopus):

    -
    $ git pull . commit-fix diff-fix
+
    $ git merge commit-fix diff-fix
 $ git show-branch
 ! [commit-fix] Fix commit message normalization.
  ! [diff-fix] Fix rename detection.
@@ -1992,7 +1957,7 @@ $ git show-branch

    Note that you should not do Octopus because you can. An octopus is a valid thing to do and often makes it easier to view the -commit history if you are pulling more than two independent +commit history if you are merging more than two independent changes at the same time. However, if you have merge conflicts with any of the branches you are merging in and need to hand resolve, that is an indication that the development happened in @@ -2004,7 +1969,7 @@ to follow, not easier.

    diff --git a/core-tutorial.txt b/core-tutorial.txt index 0cd33fb5b..7317489cf 100644 --- a/core-tutorial.txt +++ b/core-tutorial.txt @@ -906,18 +906,13 @@ of it as it can automatically (which in this case is just merge the `example` file, which had no differences in the `mybranch` branch), and say: ---------------- - Trying really trivial in-index merge... - fatal: Merge requires file-level merging - Nope. - ... Auto-merging hello CONFLICT (content): Merge conflict in hello Automatic merge failed; fix up by hand ---------------- -which is way too verbose, but it basically tells you that it failed the -really trivial merge ("Simple merge") and did an "Automatic merge" -instead, but that too failed due to conflicts in `hello`. +It tells you that it did an "Automatic merge", which +failed due to conflicts in `hello`. Not to worry. It left the (trivial) conflict in `hello` in the same form you should already be well used to if you've ever used CVS, so let's just @@ -1129,46 +1124,26 @@ juggle multiple lines of development simultaneously. Of course, you will pay the price of more disk usage to hold multiple working trees, but disk space is cheap these days. -[NOTE] -You could even pull from your own repository by -giving '.' as parameter to `git pull`. This -is useful when you want to merge a local branch (or more, if you -are making an Octopus) into the current branch. - It is likely that you will be pulling from the same remote repository from time to time. As a short hand, you can store -the remote repository URL in a file under .git/remotes/ -directory, like this: - ------------------------------------------------- -$ mkdir -p .git/remotes/ -$ cat >.git/remotes/linus <<\EOF -URL: http://www.kernel.org/pub/scm/git/git.git/ -EOF ------------------------------------------------- - -and use the filename to `git pull` instead of the full URL. -The URL specified in such file can even be a prefix -of a full URL, like this: +the remote repository URL in the local repository's config file +like this: ------------------------------------------------ -$ cat >.git/remotes/jgarzik <<\EOF -URL: http://www.kernel.org/pub/scm/linux/git/jgarzik/ -EOF +$ git repo-config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/ ------------------------------------------------ +and use the "linus" keyword with `git pull` instead of the full URL. Examples. . `git pull linus` . `git pull linus tag v0.99.1` -. `git pull jgarzik/netdev-2.6.git/ e100` the above are equivalent to: . `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD` . `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1` -. `git pull http://www.kernel.org/pub/.../jgarzik/netdev-2.6.git e100` How does the merge work? @@ -1546,7 +1521,8 @@ on that project and has an own "public repository" goes like this: 1. Prepare your work repository, by `git clone` the public repository of the "project lead". The URL used for the - initial cloning is stored in `.git/remotes/origin`. + initial cloning is stored in the remote.origin.url + configuration variable. 2. Prepare a public repository accessible to others, just like the "project lead" person does. @@ -1586,14 +1562,15 @@ like this: 1. Prepare your work repository, by `git clone` the public repository of the "project lead" (or a "subsystem maintainer", if you work on a subsystem). The URL used for - the initial cloning is stored in `.git/remotes/origin`. + the initial cloning is stored in the remote.origin.url + configuration variable. 2. Do your work in your repository on 'master' branch. 3. Run `git fetch origin` from the public repository of your upstream every once in a while. This does only the first half of `git pull` but does not merge. The head of the - public repository is stored in `.git/refs/heads/origin`. + public repository is stored in `.git/refs/remotes/origin/master`. 4. Use `git cherry origin` to see which ones of your patches were accepted, and/or use `git rebase origin` to port your @@ -1681,11 +1658,11 @@ $ git reset --hard master~2 You can make sure 'git show-branch' matches the state before those two 'git merge' you just did. Then, instead of running -two 'git merge' commands in a row, you would pull these two +two 'git merge' commands in a row, you would merge these two branch heads (this is known as 'making an Octopus'): ------------ -$ git pull . commit-fix diff-fix +$ git merge commit-fix diff-fix $ git show-branch ! [commit-fix] Fix commit message normalization. ! [diff-fix] Fix rename detection. @@ -1701,7 +1678,7 @@ $ git show-branch Note that you should not do Octopus because you can. An octopus is a valid thing to do and often makes it easier to view the -commit history if you are pulling more than two independent +commit history if you are merging more than two independent changes at the same time. However, if you have merge conflicts with any of the branches you are merging in and need to hand resolve, that is an indication that the development happened in diff --git a/everyday.html b/everyday.html index bf4bbcd1d..5c3ff9c2b 100644 --- a/everyday.html +++ b/everyday.html @@ -531,8 +531,7 @@ switch to the master branch.

  • -merge a topic branch into your master branch. You can also use -git pull . alsa-audio, i.e. pull from the local repository. +merge a topic branch into your master branch.

  • @@ -1070,7 +1069,7 @@ upload to public HTTP server hosted by your ISP. diff --git a/everyday.txt b/everyday.txt index 4e83994c5..ca36a76da 100644 --- a/everyday.txt +++ b/everyday.txt @@ -148,8 +148,7 @@ modification will be caught if you do `git commit -a` later. <8> redo the commit undone in the previous step, using the message you originally wrote. <9> switch to the master branch. -<10> merge a topic branch into your master branch. You can also use -`git pull . alsa-audio`, i.e. pull from the local repository. +<10> merge a topic branch into your master branch. <11> review commit logs; other forms to limit output can be combined and include `\--max-count=10` (show 10 commits), `\--until=2005-12-10`, etc. diff --git a/git-describe.html b/git-describe.html index f745bacb3..536fbbbe6 100644 --- a/git-describe.html +++ b/git-describe.html @@ -319,6 +319,27 @@ object name of the commit.

    abbreviated object name, use <n> digits.

    +
    +--candidates=<n> +
    +
    +

    + Instead of considering only the 10 most recent tags as + candidates to describe the input committish consider + up to <n> candidates. Increasing <n> above 10 will take + slightly longer but may produce a more accurate result. +

    +
    +
    +--debug +
    +
    +

    + Verbosely display information about the searching strategy + being employed to standard error. The tag name will still + be printed to standard out. +

    +

    EXAMPLES

    @@ -352,6 +373,23 @@ tags/v1.0.0-g975b     heads/lt/describe-g975b     +

    SEARCH STRATEGY

    +
    +

    For each committish supplied "git describe" will first look for +a tag which tags exactly that commit. Annotated tags will always +be preferred over lightweight tags, and tags with newer dates will +always be preferred over tags with older dates. If an exact match +is found, its name will be output and searching will stop.

    +

    If an exact match was not found "git describe" will walk back +through the commit history to locate an ancestor commit which +has been tagged. The ancestor's tag will be output along with an +abbreviation of the input committish's SHA1.

    +

    If multiple tags were found during the walk then the tag which +has the fewest commits different from the input committish will be +selected and output. Here fewest commits different is defined as +the number of commits which would be shown by "git log tag..input" +will be the smallest number of commits possible.

    +

    Author

    Written by Linus Torvalds <torvalds@osdl.org>, but somewhat @@ -367,7 +405,7 @@ butchered by Junio C Hamano <junkio@cox.net>

    diff --git a/git-describe.txt b/git-describe.txt index 2700f35bd..b87783cf0 100644 --- a/git-describe.txt +++ b/git-describe.txt @@ -35,6 +35,16 @@ OPTIONS Instead of using the default 8 hexadecimal digits as the abbreviated object name, use digits. +--candidates=:: + Instead of considering only the 10 most recent tags as + candidates to describe the input committish consider + up to candidates. Increasing above 10 will take + slightly longer but may produce a more accurate result. + +--debug:: + Verbosely display information about the searching strategy + being employed to standard error. The tag name will still + be printed to standard out. EXAMPLES -------- @@ -63,6 +73,26 @@ the output shows the reference path as well: [torvalds@g5 git]$ git describe --all HEAD^ heads/lt/describe-g975b +SEARCH STRATEGY +--------------- + +For each committish supplied "git describe" will first look for +a tag which tags exactly that commit. Annotated tags will always +be preferred over lightweight tags, and tags with newer dates will +always be preferred over tags with older dates. If an exact match +is found, its name will be output and searching will stop. + +If an exact match was not found "git describe" will walk back +through the commit history to locate an ancestor commit which +has been tagged. The ancestor's tag will be output along with an +abbreviation of the input committish's SHA1. + +If multiple tags were found during the walk then the tag which +has the fewest commits different from the input committish will be +selected and output. Here fewest commits different is defined as +the number of commits which would be shown by "git log tag..input" +will be the smallest number of commits possible. + Author ------ diff --git a/git-log.html b/git-log.html index e963c38e5..6ee7c7a77 100644 --- a/git-log.html +++ b/git-log.html @@ -429,7 +429,7 @@ simplification into account.

    ---max-count=<n> +-<n>

    @@ -595,7 +595,7 @@ reversible operation.

    diff --git a/git-log.txt b/git-log.txt index e9f746bbd..60610f91f 100644 --- a/git-log.txt +++ b/git-log.txt @@ -27,7 +27,7 @@ OPTIONS include::pretty-formats.txt[] ---max-count=:: +-:: Limits the number of commits to show. ..:: diff --git a/git-pull.html b/git-pull.html index 04b93fe76..0a593a8a4 100644 --- a/git-pull.html +++ b/git-pull.html @@ -743,7 +743,8 @@ git pull . fixes enhancements

    Bundle local branch fixes and enhancements on top of - the current branch, making an Octopus merge. + the current branch, making an Octopus merge. This git pull . + syntax is equivalent to git merge.

    @@ -812,7 +813,7 @@ Junio C Hamano and the git-list <git@vger.kernel.org>.

    diff --git a/git-pull.txt b/git-pull.txt index 13be99200..a90b764cc 100644 --- a/git-pull.txt +++ b/git-pull.txt @@ -52,7 +52,8 @@ git pull origin next:: git pull . fixes enhancements:: Bundle local branch `fixes` and `enhancements` on top of - the current branch, making an Octopus merge. + the current branch, making an Octopus merge. This `git pull .` + syntax is equivalent to `git merge`. git pull -s ours . obsolete:: Merge local branch `obsolete` into the current branch, diff --git a/git-repo-config.html b/git-repo-config.html index 97ff00c25..0e5a67919 100644 --- a/git-repo-config.html +++ b/git-repo-config.html @@ -1094,6 +1094,18 @@ merge.summary

    +merge.verbosity +
    +
    +

    + Controls the amount of output shown by the recursive merge + strategy. Level 0 outputs nothing except a final error + message if conflicts were detected. Level 1 outputs only + conflicts, 2 outputs conflicts and file changes. Level 5 and + above outputs debugging information. The default is level 2. +

    +
    +
    pack.window
    @@ -1268,7 +1280,7 @@ receive.denyNonFastForwards diff --git a/git-rerere.html b/git-rerere.html index d5b299cb7..a43098e16 100644 --- a/git-rerere.html +++ b/git-rerere.html @@ -362,7 +362,7 @@ One way to do it is to pull master into the topic branch:

            $ git checkout topic
-        $ git pull . master
+        $ git merge master
 
               o---*---o---+ topic
              /           /
@@ -382,10 +382,10 @@ in which case the final commit graph would look like this:
    
 
    
 
    
 
            $ git checkout topic
-        $ git pull . master
+        $ git merge master
         $ ... work on both topic and master branches
         $ git checkout master
-        $ git pull . topic
+        $ git merge topic
 
               o---*---o---+---o---o topic
              /           /         \
@@ -403,11 +403,11 @@ top of the tip before the test merge:
    
 
    
 
    
 
            $ git checkout topic
-        $ git pull . master
+        $ git merge master
         $ git reset --hard HEAD^ ;# rewind the test merge
         $ ... work on both topic and master branches
         $ git checkout master
-        $ git pull . topic
+        $ git merge topic
 
               o---*---o-------o---o topic
              /                     \
@@ -482,7 +482,7 @@ conflict.
    
 
    
 
 
diff --git a/git-rerere.txt b/git-rerere.txt
index b57a72bdd..08a055713 100644
--- a/git-rerere.txt
+++ b/git-rerere.txt
@@ -81,7 +81,7 @@ One way to do it is to pull master into the topic branch:
 
 ------------
 	$ git checkout topic
-	$ git pull . master
+	$ git merge master
 
               o---*---o---+ topic
              /           /
@@ -103,10 +103,10 @@ in which case the final commit graph would look like this:
 
 ------------
 	$ git checkout topic
-	$ git pull . master
+	$ git merge master
 	$ ... work on both topic and master branches
 	$ git checkout master
-	$ git pull . topic
+	$ git merge topic
 
               o---*---o---+---o---o topic
              /           /         \
@@ -126,11 +126,11 @@ top of the tip before the test merge:
 
 ------------
 	$ git checkout topic
-	$ git pull . master
+	$ git merge master
 	$ git reset --hard HEAD^ ;# rewind the test merge
 	$ ... work on both topic and master branches
 	$ git checkout master
-	$ git pull . topic
+	$ git merge topic
 
               o---*---o-------o---o topic
              /                     \
diff --git a/git-reset.html b/git-reset.html
index d331aba3f..86fcfd3b5 100644
--- a/git-reset.html
+++ b/git-reset.html
@@ -468,10 +468,6 @@ Undo a merge or pull
 
    
 
    
 
    $ git pull                         (1)
-Trying really trivial in-index merge...
-fatal: Merge requires file-level merging
-Nope.
-...
 Auto-merging nitfol
 CONFLICT (content): Merge conflict in nitfol
 Automatic merge failed/prevented; fix up by hand
@@ -570,7 +566,7 @@ At this point the index file still has all the WIP changes you
 
    
 
 
diff --git a/git-reset.txt b/git-reset.txt
index 4f424782e..04475a921 100644
--- a/git-reset.txt
+++ b/git-reset.txt
@@ -121,10 +121,6 @@ Undo a merge or pull::
 +
 ------------
 $ git pull                         <1>
-Trying really trivial in-index merge...
-fatal: Merge requires file-level merging
-Nope.
-...
 Auto-merging nitfol
 CONFLICT (content): Merge conflict in nitfol
 Automatic merge failed/prevented; fix up by hand
diff --git a/tutorial.html b/tutorial.html
index d88def37e..c6b5ff62a 100644
--- a/tutorial.html
+++ b/tutorial.html
@@ -271,15 +271,13 @@ diff" with:
    
 
    
 
    $ man git-diff
    
 
    
-
    It is a good idea to introduce yourself to git before doing any
-operation.  The easiest way to do so is:
    
+
    It is a good idea to introduce yourself to git with your name and
+public email address before doing any operation.  The easiest
+way to do so is:
    
 
    
 
    
-
    $ cat >~/.gitconfig <<\EOF
-[user]
-        name = Your Name Comes Here
-        email = you@yourdomain.example.com
-EOF
    
+
    $ git repo-config --global user.name "Your Name Comes Here"
+$ git repo-config --global user.email you@yourdomain.example.com
    
 
    
 
    
 
    
@@ -448,7 +446,7 @@ $ git commit -a
    made in each. To merge the changes made in experimental into master, run

    -
    $ git pull . experimental
    +
    $ git merge experimental

    If the changes don't conflict, you're done. If there are conflicts, markers will be left in the problematic files showing the conflict;

    @@ -534,13 +532,13 @@ named bob-incoming. Then

    shows a list of all the changes that Bob made since he branched from Alice's master branch.

    After examining those changes, and possibly fixing things, Alice -could pull the changes into her master branch:

    +could merge the changes into her master branch:

    $ git checkout master
-$ git pull . bob-incoming
    +$ git merge bob-incoming
    -

    The last command is a pull from the "bob-incoming" branch in Alice's +

    The last command is a merge from the "bob-incoming" branch in Alice's own repository.

    Alice could also perform both steps at once with:

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

    diff --git a/tutorial.txt b/tutorial.txt index d2bf0b905..8325c5e53 100644 --- a/tutorial.txt +++ b/tutorial.txt @@ -11,15 +11,13 @@ diff" with: $ man git-diff ------------------------------------------------ -It is a good idea to introduce yourself to git before doing any -operation. The easiest way to do so is: +It is a good idea to introduce yourself to git with your name and +public email address before doing any operation. The easiest +way to do so is: ------------------------------------------------ -$ cat >~/.gitconfig <<\EOF -[user] - name = Your Name Comes Here - email = you@yourdomain.example.com -EOF +$ git repo-config --global user.name "Your Name Comes Here" +$ git repo-config --global user.email you@yourdomain.example.com ------------------------------------------------ @@ -211,7 +209,7 @@ at this point the two branches have diverged, with different changes made in each. To merge the changes made in experimental into master, run ------------------------------------------------ -$ git pull . experimental +$ git merge experimental ------------------------------------------------ If the changes don't conflict, you're done. If there are conflicts, @@ -316,14 +314,14 @@ shows a list of all the changes that Bob made since he branched from Alice's master branch. After examining those changes, and possibly fixing things, Alice -could pull the changes into her master branch: +could merge the changes into her master branch: ------------------------------------- $ git checkout master -$ git pull . bob-incoming +$ git merge bob-incoming ------------------------------------- -The last command is a pull from the "bob-incoming" branch in Alice's +The last command is a merge from the "bob-incoming" branch in Alice's own repository. Alice could also perform both steps at once with: -- 2.26.2