From: Junio C Hamano Date: Tue, 3 Jul 2007 07:05:31 +0000 (+0000) Subject: Autogenerated HTML docs for v1.5.3-rc0 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=1d90cb06fff9524ece5485f8d716da466af822d7;p=git.git Autogenerated HTML docs for v1.5.3-rc0 --- diff --git a/RelNotes-1.5.2.3.txt b/RelNotes-1.5.2.3.txt new file mode 100644 index 000000000..addb22955 --- /dev/null +++ b/RelNotes-1.5.2.3.txt @@ -0,0 +1,27 @@ +GIT v1.5.2.3 Release Notes +========================== + +Fixes since v1.5.2.2 +-------------------- + + * Bugfixes + + - Version 2 pack index format was introduced in version 1.5.2 + to support pack files that has offset that cannot be + represented in 32-bit. The runtime code to validate such + an index mishandled such an index for an empty pack. + + - Commit walkers (most notably, fetch over http protocol) + tried to traverse commit objects contained in trees (aka + subproject); they shouldn't. + + - A build option NO_R_TO_GCC_LINKER was not explained in Makefile + comment correctly. + + * Documentation Fixes and Updates + + - git-config --regexp was not documented properly. + + - git-repack -a was not documented properly. + + - git-remote -n was not documented properly. diff --git a/cmds-mainporcelain.txt b/cmds-mainporcelain.txt index 2c3697c69..a87814bbe 100644 --- a/cmds-mainporcelain.txt +++ b/cmds-mainporcelain.txt @@ -94,6 +94,9 @@ gitlink:git-shortlog[1]:: gitlink:git-show[1]:: Show various types of objects. +gitlink:git-stash[1]:: + Stash the changes in a dirty working directory away. + gitlink:git-status[1]:: Show the working tree status. diff --git a/config.txt b/config.txt index 50503e84b..1d96adf30 100644 --- a/config.txt +++ b/config.txt @@ -275,7 +275,7 @@ You probably do not need to adjust this value. + Common unit suffixes of 'k', 'm', or 'g' are supported. -core.excludeFile:: +core.excludesfile:: In addition to '.gitignore' (per-directory) and '.git/info/exclude', git looks into this file for patterns of files which are not meant to be tracked. See diff --git a/git-branch.html b/git-branch.html index 22a51bfc7..c4afc68eb 100644 --- a/git-branch.html +++ b/git-branch.html @@ -302,7 +302,7 @@ renaming. If <newbranch> exists, -M must be used to force the rename to happen.

With a -d or -D option, <branchname> will be deleted. You may specify more than one branch for deletion. If the branch currently -has a ref log then the ref log will also be deleted. Use -r together with -d +has a reflog then the reflog will also be deleted. Use -r together with -d to delete remote-tracking branches.

OPTIONS

@@ -329,8 +329,9 @@ to delete remote-tracking branches.

- Create the branch's ref log. This activates recording of - all changes to made the branch ref, enabling use of date + Create the branch's reflog. This activates recording of + all changes made to the branch ref, enabling use of date + based sha1 expressions such as "<branchname>@{yesterday}".

@@ -526,7 +527,7 @@ a branch and check it out with a single command.

diff --git a/git-branch.txt b/git-branch.txt index 8d72bb936..bb6b57dc2 100644 --- a/git-branch.txt +++ b/git-branch.txt @@ -41,7 +41,7 @@ to happen. With a `-d` or `-D` option, `` will be deleted. You may specify more than one branch for deletion. If the branch currently -has a ref log then the ref log will also be deleted. Use -r together with -d +has a reflog then the reflog will also be deleted. Use -r together with -d to delete remote-tracking branches. @@ -54,9 +54,9 @@ OPTIONS Delete a branch irrespective of its index status. -l:: - Create the branch's ref log. This activates recording of - all changes to made the branch ref, enabling use of date - based sha1 expressions such as "@{yesterday}". + Create the branch's reflog. This activates recording of + all changes made to the branch ref, enabling use of date + based sha1 expressions such as "@\{yesterday}". -f:: Force the creation of a new branch even if it means deleting diff --git a/git-checkout.html b/git-checkout.html index 15ed96d6c..43989db03 100644 --- a/git-checkout.html +++ b/git-checkout.html @@ -354,8 +354,9 @@ working tree.

- Create the new branch's ref log. This activates recording of - all changes to made the branch ref, enabling use of date + Create the new branch's reflog. This activates recording of + all changes made to the branch ref, enabling use of date + based sha1 expressions such as "<branchname>@{yesterday}".

@@ -537,7 +538,7 @@ $ git add frotz diff --git a/git-checkout.txt b/git-checkout.txt index ea26da8e2..818b720b9 100644 --- a/git-checkout.txt +++ b/git-checkout.txt @@ -62,9 +62,9 @@ OPTIONS configuration variable. -l:: - Create the new branch's ref log. This activates recording of - all changes to made the branch ref, enabling use of date - based sha1 expressions such as "@{yesterday}". + Create the new branch's reflog. This activates recording of + all changes made to the branch ref, enabling use of date + based sha1 expressions such as "@\{yesterday}". -m:: If you have local modifications to one or more files that diff --git a/git-config.html b/git-config.html index afc81832b..671937a47 100644 --- a/git-config.html +++ b/git-config.html @@ -1001,7 +1001,7 @@ You probably do not need to adjust this value.

Common unit suffixes of k, m, or g are supported.

-core.excludeFile +core.excludesfile

@@ -1820,7 +1820,7 @@ transfer.unpackLimit

diff --git a/git-format-patch.html b/git-format-patch.html index b5c99f8b1..05b0da062 100644 --- a/git-format-patch.html +++ b/git-format-patch.html @@ -828,12 +828,13 @@ not add any suffix.

CONFIGURATION

You can specify extra mail header lines to be added to each -message in the repository configuration. Also you can specify -the default suffix different from the built-in one:

+message in the repository configuration. You can also specify +new defaults for the subject prefix and file suffix.

[format]
         headers = "Organization: git-foo\n"
+        subjectprefix = CHANGE
         suffix = .txt
@@ -903,7 +904,7 @@ git-format-patch -3 diff --git a/git-format-patch.txt b/git-format-patch.txt index 647de9036..e5638102e 100644 --- a/git-format-patch.txt +++ b/git-format-patch.txt @@ -126,12 +126,13 @@ not add any suffix. CONFIGURATION ------------- You can specify extra mail header lines to be added to each -message in the repository configuration. Also you can specify -the default suffix different from the built-in one: +message in the repository configuration. You can also specify +new defaults for the subject prefix and file suffix. ------------ [format] headers = "Organization: git-foo\n" + subjectprefix = CHANGE suffix = .txt ------------ diff --git a/git-fsck.html b/git-fsck.html index 051d7cc2f..91af94b7f 100644 --- a/git-fsck.html +++ b/git-fsck.html @@ -274,7 +274,7 @@ git-fsck(1) Manual Page
git-fsck [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] - [--full] [--strict] [--verbose] [<object>*]
+ [--full] [--strict] [--verbose] [--lost-found] [<object>*]

DESCRIPTION

@@ -373,6 +373,15 @@ index file and all SHA1 references in .git/refs/* as heads.

Be chatty.

+
+--lost-found +
+
+

+ Write dangling refs into .git/commit/ or .git/other/, depending + on type. +

+

It tests SHA1 and general object sanity, and it does full tracking of the resulting reachability and everything else. It prints out any @@ -510,7 +519,7 @@ GIT_ALTERNATE_OBJECT_DIRECTORIES

diff --git a/git-fsck.txt b/git-fsck.txt index 234c22f57..08512e0b8 100644 --- a/git-fsck.txt +++ b/git-fsck.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] 'git-fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] - [--full] [--strict] [--verbose] [*] + [--full] [--strict] [--verbose] [--lost-found] [*] DESCRIPTION ----------- @@ -64,6 +64,10 @@ index file and all SHA1 references in .git/refs/* as heads. --verbose:: Be chatty. +--lost-found:: + Write dangling refs into .git/commit/ or .git/other/, depending + on type. + It tests SHA1 and general object sanity, and it does full tracking of the resulting reachability and everything else. It prints out any corruption it finds (missing or bad objects), and if you use the diff --git a/git-init-db.html b/git-init-db.html index 278cfc13c..90fbd4147 100644 --- a/git-init-db.html +++ b/git-init-db.html @@ -272,7 +272,7 @@ git-init-db(1) Manual Page

SYNOPSIS

-

git-init-db [--template=<template_directory>] [--shared[=<permissions>]]

+

git-init-db [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]

DESCRIPTION

@@ -281,7 +281,7 @@ documentation of that command.

diff --git a/git-init-db.txt b/git-init-db.txt index ab0201aec..d4e01cb32 100644 --- a/git-init-db.txt +++ b/git-init-db.txt @@ -8,7 +8,7 @@ git-init-db - Creates an empty git repository SYNOPSIS -------- -'git-init-db' [--template=] [--shared[=]] +'git-init-db' [-q | --quiet] [--template=] [--shared[=]] DESCRIPTION diff --git a/git-init.html b/git-init.html index b3216462e..3821c8993 100644 --- a/git-init.html +++ b/git-init.html @@ -272,12 +272,20 @@ git-init(1) Manual Page

SYNOPSIS

-

git-init [--template=<template_directory>] [--shared[=<permissions>]]

+

git-init [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]

OPTIONS

+-q, --quiet +
+
+

+Only print error and warning messages, all other output will be suppressed. +

+
+
--template=<template_directory>
@@ -395,7 +403,7 @@ add all existing file to the index
diff --git a/git-init.txt b/git-init.txt index 413ed6514..07484a4fd 100644 --- a/git-init.txt +++ b/git-init.txt @@ -8,7 +8,7 @@ git-init - Create an empty git repository or reinitialize an existing one SYNOPSIS -------- -'git-init' [--template=] [--shared[=]] +'git-init' [-q | --quiet] [--template=] [--shared[=]] OPTIONS @@ -16,6 +16,10 @@ OPTIONS -- +-q, \--quiet:: + +Only print error and warning messages, all other output will be suppressed. + --template=:: Provide the directory from which templates will be used. The default template diff --git a/git-local-fetch.html b/git-local-fetch.html index 927b5eb82..dc11f4054 100644 --- a/git-local-fetch.html +++ b/git-local-fetch.html @@ -278,6 +278,7 @@ git-local-fetch(1) Manual Page

DESCRIPTION

+

THIS COMMAND IS DEPRECATED.

Duplicates another git repository on a local system.

OPTIONS

@@ -390,7 +391,7 @@ git-local-fetch(1) Manual Page diff --git a/git-local-fetch.txt b/git-local-fetch.txt index 19b5f8895..141b76768 100644 --- a/git-local-fetch.txt +++ b/git-local-fetch.txt @@ -14,6 +14,8 @@ SYNOPSIS DESCRIPTION ----------- +THIS COMMAND IS DEPRECATED. + Duplicates another git repository on a local system. OPTIONS diff --git a/git-rebase.html b/git-rebase.html index 2ccbda92a..90e8e57bd 100644 --- a/git-rebase.html +++ b/git-rebase.html @@ -273,7 +273,8 @@ git-rebase(1) Manual Page

SYNOPSIS

-
git-rebase [-v] [--merge] [-C<n>] [--onto <newbase>] <upstream> [<branch>] +
git-rebase [-i | --interactive] [-v | --verbose] [--merge] [-C<n>] + [-p | --preserve-merges] [--onto <newbase>] <upstream> [<branch>] git-rebase --continue | --skip | --abort

DESCRIPTION

@@ -508,6 +509,24 @@ desired resolution, you can continue the rebasing process with

ever ignored.

+
+-i, --interactive +
+
+

+ Make a list of the commits which are about to be rebased. Let the + user edit that list before rebasing. +

+
+
+-p, --preserve-merges +
+
+

+ Instead of ignoring merges, try to recreate them. This option + only works in interactive mode. +

+

MERGE STRATEGIES

@@ -582,9 +601,138 @@ pre-rebase hook script for an example.

You must be in the top directory of your project to start (or continue) a rebase. Upon completion, <branch> will be the current branch.

-

Author

+

INTERACTIVE MODE

+
+

Rebasing interactively means that you have a chance to edit the commits +which are rebased. You can reorder the commits, and you can +remove them (weeding out bad or otherwise unwanted patches).

+

The interactive mode is meant for this type of workflow:

+
    +
  1. +

    +have a wonderful idea +

    +
    2. +
  2. +

    +hack on the code +

    +
    3. +
  3. +

    +prepare a series for submission +

    +
    4. +
  4. +

    +submit +

    +
    5. +
+

where point 2. consists of several instances of

+
    +
  1. +

    +regular use +

    +
      +
    1. +

      +finish something worthy of a commit +

      +
      2. +
    2. +

      +commit +

      +
      3. +
    +
    2. +
  2. +

    +independent fixup +

    +
      +
    1. +

      +realize that something does not work +

      +
      2. +
    2. +

      +fix that +

      +
      3. +
    3. +

      +commit it +

      +
      4. +
    +
    3. +
+

Sometimes the thing fixed in b.2. cannot be amended to the not-quite +perfect commit it fixes, because that commit is buried deeply in a +patch series. That is exactly what interactive rebase is for: use it +after plenty of "a"s and "b"s, by rearranging and editing +commits, and squashing multiple commits into one.

+

Start it with the last commit you want to retain as-is:

+
+
+
git rebase -i <after-this-commit>
+
+

An editor will be fired up with all the commits in your current branch +(ignoring merge commits), which come after the given commit. You can +reorder the commits in this list to your heart's content, and you can +remove them. The list looks more or less like this:

+
+
+
pick deadbee The oneline of this commit
+pick fa1afe1 The oneline of the next commit
+...
+
+

The oneline descriptions are purely for your pleasure; git-rebase will +not look at them but at the commit names ("deadbee" and "fa1afe1" in this +example), so do not delete or edit the names.

+

By replacing the command "pick" with the command "edit", you can tell +git-rebase to stop after applying that commit, so that you can edit +the files and/or the commit message, amend the commit, and continue +rebasing.

+

If you want to fold two or more commits into one, replace the command +"pick" with "squash" for the second and subsequent commit. If the +commits had different authors, it will attribute the squashed commit to +the author of the last commit.

+

In both cases, or when a "pick" does not succeed (because of merge +errors), the loop will stop to let you fix things, and you can continue +the loop with git rebase --continue.

+

For example, if you want to reorder the last 5 commits, such that what +was HEAD~4 becomes the new HEAD. To achieve that, you would call +git-rebase like this:

+
+
+
$ git rebase -i HEAD~5
+
+

And move the first patch to the end of the list.

+

You might want to preserve merges, if you have a history like this:

+
+
+
           X
+            \
+         A---M---B
+        /
+---o---O---P---Q
+
+

Suppose you want to rebase the side branch starting at "A" to "Q". Make +sure that the current HEAD is "B", and call

+
+
+
$ git rebase -i -p --onto Q O
+
+
+

Authors

-

Written by Junio C Hamano <junkio@cox.net>

+

Written by Junio C Hamano <junkio@cox.net> and +Johannes E. Schindelin <johannes.schindelin@gmx.de>

Documentation

@@ -596,7 +744,7 @@ a rebase. Upon completion, <branch> will be the current branch.

diff --git a/git-rebase.txt b/git-rebase.txt index 0c00090a6..96907d486 100644 --- a/git-rebase.txt +++ b/git-rebase.txt @@ -8,7 +8,8 @@ git-rebase - Forward-port local commits to the updated upstream head SYNOPSIS -------- [verse] -'git-rebase' [-v] [--merge] [-C] [--onto ] [] +'git-rebase' [-i | --interactive] [-v | --verbose] [--merge] [-C] + [-p | --preserve-merges] [--onto ] [] 'git-rebase' --continue | --skip | --abort DESCRIPTION @@ -208,6 +209,14 @@ OPTIONS context exist they all must match. By default no context is ever ignored. +-i, \--interactive:: + Make a list of the commits which are about to be rebased. Let the + user edit that list before rebasing. + +-p, \--preserve-merges:: + Instead of ignoring merges, try to recreate them. This option + only works in interactive mode. + include::merge-strategies.txt[] NOTES @@ -226,9 +235,100 @@ pre-rebase hook script for an example. You must be in the top directory of your project to start (or continue) a rebase. Upon completion, will be the current branch. -Author +INTERACTIVE MODE +---------------- + +Rebasing interactively means that you have a chance to edit the commits +which are rebased. You can reorder the commits, and you can +remove them (weeding out bad or otherwise unwanted patches). + +The interactive mode is meant for this type of workflow: + +1. have a wonderful idea +2. hack on the code +3. prepare a series for submission +4. submit + +where point 2. consists of several instances of + +a. regular use + 1. finish something worthy of a commit + 2. commit +b. independent fixup + 1. realize that something does not work + 2. fix that + 3. commit it + +Sometimes the thing fixed in b.2. cannot be amended to the not-quite +perfect commit it fixes, because that commit is buried deeply in a +patch series. That is exactly what interactive rebase is for: use it +after plenty of "a"s and "b"s, by rearranging and editing +commits, and squashing multiple commits into one. + +Start it with the last commit you want to retain as-is: + + git rebase -i + +An editor will be fired up with all the commits in your current branch +(ignoring merge commits), which come after the given commit. You can +reorder the commits in this list to your heart's content, and you can +remove them. The list looks more or less like this: + +------------------------------------------- +pick deadbee The oneline of this commit +pick fa1afe1 The oneline of the next commit +... +------------------------------------------- + +The oneline descriptions are purely for your pleasure; `git-rebase` will +not look at them but at the commit names ("deadbee" and "fa1afe1" in this +example), so do not delete or edit the names. + +By replacing the command "pick" with the command "edit", you can tell +`git-rebase` to stop after applying that commit, so that you can edit +the files and/or the commit message, amend the commit, and continue +rebasing. + +If you want to fold two or more commits into one, replace the command +"pick" with "squash" for the second and subsequent commit. If the +commits had different authors, it will attribute the squashed commit to +the author of the last commit. + +In both cases, or when a "pick" does not succeed (because of merge +errors), the loop will stop to let you fix things, and you can continue +the loop with `git rebase --continue`. + +For example, if you want to reorder the last 5 commits, such that what +was HEAD~4 becomes the new HEAD. To achieve that, you would call +`git-rebase` like this: + +---------------------- +$ git rebase -i HEAD~5 +---------------------- + +And move the first patch to the end of the list. + +You might want to preserve merges, if you have a history like this: + +------------------ + X + \ + A---M---B + / +---o---O---P---Q +------------------ + +Suppose you want to rebase the side branch starting at "A" to "Q". Make +sure that the current HEAD is "B", and call + +----------------------------- +$ git rebase -i -p --onto Q O +----------------------------- + +Authors ------ -Written by Junio C Hamano +Written by Junio C Hamano and +Johannes E. Schindelin Documentation -------------- diff --git a/git-receive-pack.html b/git-receive-pack.html index 6de8debec..6e52400dc 100644 --- a/git-receive-pack.html +++ b/git-receive-pack.html @@ -317,6 +317,8 @@ standard input of the hook will be one line per ref to be updated:

The refname value is relative to $GIT_DIR; e.g. for the master head this is "refs/heads/master". The two sha1 values before each refname are the object names for the refname before and after +the update. Refs to be created will have sha1-old equal to 0{40}, +while refs to be deleted will have sha1-new equal to 0{40}, otherwise sha1-old and sha1-new should be valid objects in the repository.

This hook is called before any refname is updated and before any fast-forward checks are performed.

@@ -337,6 +339,7 @@ and is executable, it is invoked once per ref, with three parameters:

head this is "refs/heads/master". The two sha1 arguments are the object names for the refname before and after the update. Note that the hook is called before the refname is updated, +so either sha1-old is 0{40} (meaning there is no such ref yet), or it should match what is recorded in refname.

The hook should exit with non-zero status if it wants to disallow updating the named ref. Otherwise it should exit with zero.

@@ -360,6 +363,8 @@ for each successfully updated ref:

head this is "refs/heads/master". The two sha1 values before each refname are the object names for the refname before and after the update. Refs that were created will have sha1-old equal to +0{40}, while refs that were deleted will have sha1-new equal to +0{40}, otherwise sha1-old and sha1-new should be valid objects in the repository.

Using this hook, it is easy to generate mails describing the updates to the repository. This example script sends one mail message per @@ -425,7 +430,7 @@ exec git-update-server-info

diff --git a/git-receive-pack.txt b/git-receive-pack.txt index 6914aa59c..4ef184047 100644 --- a/git-receive-pack.txt +++ b/git-receive-pack.txt @@ -48,8 +48,8 @@ standard input of the hook will be one line per ref to be updated: The refname value is relative to $GIT_DIR; e.g. for the master head this is "refs/heads/master". The two sha1 values before each refname are the object names for the refname before and after -the update. Refs to be created will have sha1-old equal to 0{40}, -while refs to be deleted will have sha1-new equal to 0{40}, otherwise +the update. Refs to be created will have sha1-old equal to 0\{40}, +while refs to be deleted will have sha1-new equal to 0\{40}, otherwise sha1-old and sha1-new should be valid objects in the repository. This hook is called before any refname is updated and before any @@ -71,7 +71,7 @@ The refname parameter is relative to $GIT_DIR; e.g. for the master head this is "refs/heads/master". The two sha1 arguments are the object names for the refname before and after the update. Note that the hook is called before the refname is updated, -so either sha1-old is 0{40} (meaning there is no such ref yet), +so either sha1-old is 0\{40} (meaning there is no such ref yet), or it should match what is recorded in refname. The hook should exit with non-zero status if it wants to disallow @@ -96,8 +96,8 @@ The refname value is relative to $GIT_DIR; e.g. for the master head this is "refs/heads/master". The two sha1 values before each refname are the object names for the refname before and after the update. Refs that were created will have sha1-old equal to -0{40}, while refs that were deleted will have sha1-new equal to -0{40}, otherwise sha1-old and sha1-new should be valid objects in +0\{40}, while refs that were deleted will have sha1-new equal to +0\{40}, otherwise sha1-old and sha1-new should be valid objects in the repository. Using this hook, it is easy to generate mails describing the updates diff --git a/git-rev-list.html b/git-rev-list.html index 99d70746c..bb8df2cde 100644 --- a/git-rev-list.html +++ b/git-rev-list.html @@ -670,6 +670,7 @@ excluded from the output. nor commit1…commit2 notations cannot be used).
With --pretty format other than oneline (for obvious reasons), this causes the output to have two extra lines of information +taken from the reflog. By default, commit@{Nth} notation is used in the output. When the starting commit is specified as instead. Under --pretty=oneline, the commit message is prefixed with this information on the same line. @@ -1109,7 +1110,7 @@ and the git-list <git@vger.kernel.org>.

diff --git a/git-rev-list.txt b/git-rev-list.txt index 32cb13fae..20dcac625 100644 --- a/git-rev-list.txt +++ b/git-rev-list.txt @@ -284,9 +284,9 @@ excluded from the output. + With '\--pretty' format other than oneline (for obvious reasons), this causes the output to have two extra lines of information -taken from the reflog. By default, 'commit@{Nth}' notation is +taken from the reflog. By default, 'commit@\{Nth}' notation is used in the output. When the starting commit is specified as -'commit@{now}', output also uses 'commit@{timestamp}' notation +'commit@{now}', output also uses 'commit@\{timestamp}' notation instead. Under '\--pretty=oneline', the commit message is prefixed with this information on the same line. diff --git a/git-ssh-fetch.html b/git-ssh-fetch.html index 7b59e117b..384a5f093 100644 --- a/git-ssh-fetch.html +++ b/git-ssh-fetch.html @@ -276,6 +276,7 @@ git-ssh-fetch(1) Manual Page

DESCRIPTION

+

THIS COMMAND IS DEPRECATED.

Pulls from a remote repository over ssh connection, invoking git-ssh-upload on the other end. It functions identically to git-ssh-upload, aside from which end you run it on.

@@ -349,7 +350,7 @@ commit-id
diff --git a/git-ssh-fetch.txt b/git-ssh-fetch.txt index aaf3db06d..8d3e2ffb2 100644 --- a/git-ssh-fetch.txt +++ b/git-ssh-fetch.txt @@ -13,6 +13,8 @@ SYNOPSIS DESCRIPTION ----------- +THIS COMMAND IS DEPRECATED. + Pulls from a remote repository over ssh connection, invoking git-ssh-upload on the other end. It functions identically to git-ssh-upload, aside from which end you run it on. diff --git a/git-ssh-upload.html b/git-ssh-upload.html index 69cbc3a71..f18fd1daf 100644 --- a/git-ssh-upload.html +++ b/git-ssh-upload.html @@ -276,6 +276,7 @@ git-ssh-upload(1) Manual Page

DESCRIPTION

+

THIS COMMAND IS DEPRECATED.

Pushes from a remote repository over ssh connection, invoking git-ssh-fetch on the other end. It functions identically to git-ssh-fetch, aside from which end you run it on.

@@ -348,7 +349,7 @@ commit-id
diff --git a/git-ssh-upload.txt b/git-ssh-upload.txt index 479622424..5e2ca8dcc 100644 --- a/git-ssh-upload.txt +++ b/git-ssh-upload.txt @@ -12,6 +12,8 @@ SYNOPSIS DESCRIPTION ----------- +THIS COMMAND IS DEPRECATED. + Pushes from a remote repository over ssh connection, invoking git-ssh-fetch on the other end. It functions identically to git-ssh-fetch, aside from which end you run it on. diff --git a/git-stash.html b/git-stash.html new file mode 100644 index 000000000..9ec4029e8 --- /dev/null +++ b/git-stash.html @@ -0,0 +1,460 @@ + + + + + + +git-stash(1) + + + +

SYNOPSIS

+
+
+
git-stash (save | list | show [<stash>] | apply [<stash>] | clear)
+
+

DESCRIPTION

+
+

Use git-stash when you want to record the current state of the +working directory and the index, but want to go back to a clean +working directory. The command saves your local modifications away +and reverts the working directory to match the HEAD commit.

+

The modifications stashed away by this command can be listed with +git-stash list, inspected with git-stash show, and restored +(potentially on top of a different commit) with git-stash apply. +Calling git-stash without any arguments is equivalent to git-stash +save.

+

The latest stash you created is stored in $GIT_DIR/refs/stash; older +stashes are found in the reflog of this reference and can be named using +the usual reflog syntax (e.g. stash@{1} is the most recently +created stash, stash@{2} is the one before it, stash@{2.hours.ago} +is also possible).

+
+

OPTIONS

+
+
+
+save +
+
+

+ Save your local modifications to a new stash, and run git-reset + --hard to revert them. This is the default action when no + subcommand is given. +

+
+
+list +
+
+

+ List the stashes that you currently have. Each stash is listed + with its name (e.g. stash@{0} is the latest stash, `stash@{1} is + the one before, etc.), the name of the branch that was current when the + stash was made, and a short description of the commit the stash was + based on. +

+
+
+
stash@{0}: submit: 6ebd0e2... Add git-stash
+stash@{1}: master: 9cc0589... Merge branch 'master' of gfi
+
+
+
+show [<stash>] +
+
+

+ Show the changes recorded in the stash as a diff between the the + stashed state and its original parent. When no <stash> is given, + shows the latest one. By default, the command shows the diffstat, but + it will accept any format known to git-diff (e.g., git-stash show + -p stash@{2} to view the second most recent stash in patch form). +

+
+
+apply [<stash>] +
+
+

+ Restore the changes recorded in the stash on top of the current + working tree state. When no <stash> is given, applies the latest + one. The working directory must match the index. +

+

This operation can fail with conflicts; you need to resolve them +by hand in the working tree.

+
+
+clear +
+
+

+ Remove all the stashed states. Note that those states will then + be subject to pruning, and may be difficult or impossible to recover. +

+
+
+
+

DISCUSSION

+
+

A stash is represented as a commit whose tree records the state of the +working directory, and its first parent is the commit at HEAD when +the stash was created. The tree of the second parent records the +state of the index when the stash is made, and it is made a child of +the HEAD commit. The ancestry graph looks like this:

+
+
+
       .----W
+      /    /
+...--H----I
+
+

where H is the HEAD commit, I is a commit that records the state +of the index, and W is a commit that records the state of the working +tree.

+
+

EXAMPLES

+
+
+
+Pulling into a dirty tree +
+
+

+When you are in the middle of something, you learn that there are +upstream changes that are possibly relevant to what you are +doing. When your local changes do not conflict with the changes in +the upstream, a simple git pull will let you move forward. +

+

However, there are cases in which your local changes do conflict with +the upstream changes, and git pull refuses to overwrite your +changes. In such a case, you can stash your changes away, +perform a pull, and then unstash, like this:

+
+
+
$ git pull
+...
+file foobar not up to date, cannot merge.
+$ git stash
+$ git pull
+$ git stash apply
+
+
+
+Interrupted workflow +
+
+

+When you are in the middle of something, your boss comes in and +demands that you fix something immediately. Traditionally, you would +make a commit to a temporary branch to store your changes away, and +return to your original branch to make the emergency fix, like this: +

+
+
+
... hack hack hack ...
+$ git checkout -b my_wip
+$ git commit -a -m "WIP"
+$ git checkout master
+$ edit emergency fix
+$ git commit -a -m "Fix in a hurry"
+$ git checkout my_wip
+$ git reset --soft HEAD^
+... continue hacking ...
+
+

You can use git-stash to simplify the above, like this:

+
+
+
... hack hack hack ...
+$ git stash
+$ edit emergency fix
+$ git commit -a -m "Fix in a hurry"
+$ git stash apply
+... continue hacking ...
+
+
+
+
+

SEE ALSO

+
+

git-checkout(1), +git-commit(1), +git-reflog(1), +git-reset(1)

+
+

AUTHOR

+
+

Written by Nanako Shiraishi <nanako3@bluebottle.com>

+
+

GIT

+
+

Part of the git(7) suite

+
+ + + diff --git a/git-stash.txt b/git-stash.txt new file mode 100644 index 000000000..35888b43c --- /dev/null +++ b/git-stash.txt @@ -0,0 +1,162 @@ +git-stash(1) +============ + +NAME +---- +git-stash - Stash the changes in a dirty working directory away + +SYNOPSIS +-------- +[verse] +'git-stash' (save | list | show [] | apply [] | clear) + +DESCRIPTION +----------- + +Use 'git-stash' when you want to record the current state of the +working directory and the index, but want to go back to a clean +working directory. The command saves your local modifications away +and reverts the working directory to match the `HEAD` commit. + +The modifications stashed away by this command can be listed with +`git-stash list`, inspected with `git-stash show`, and restored +(potentially on top of a different commit) with `git-stash apply`. +Calling git-stash without any arguments is equivalent to `git-stash +save`. + +The latest stash you created is stored in `$GIT_DIR/refs/stash`; older +stashes are found in the reflog of this reference and can be named using +the usual reflog syntax (e.g. `stash@\{1}` is the most recently +created stash, `stash@\{2}` is the one before it, `stash@\{2.hours.ago}` +is also possible). + +OPTIONS +------- + +save:: + + Save your local modifications to a new 'stash', and run `git-reset + --hard` to revert them. This is the default action when no + subcommand is given. + +list:: + + List the stashes that you currently have. Each 'stash' is listed + with its name (e.g. `stash@\{0}` is the latest stash, `stash@\{1} is + the one before, etc.), the name of the branch that was current when the + stash was made, and a short description of the commit the stash was + based on. ++ +---------------------------------------------------------------- +stash@{0}: submit: 6ebd0e2... Add git-stash +stash@{1}: master: 9cc0589... Merge branch 'master' of gfi +---------------------------------------------------------------- + +show []:: + + Show the changes recorded in the stash as a diff between the the + stashed state and its original parent. When no `` is given, + shows the latest one. By default, the command shows the diffstat, but + it will accept any format known to `git-diff` (e.g., `git-stash show + -p stash@\{2}` to view the second most recent stash in patch form). + +apply []:: + + Restore the changes recorded in the stash on top of the current + working tree state. When no `` is given, applies the latest + one. The working directory must match the index. ++ +This operation can fail with conflicts; you need to resolve them +by hand in the working tree. + +clear:: + Remove all the stashed states. Note that those states will then + be subject to pruning, and may be difficult or impossible to recover. + + +DISCUSSION +---------- + +A stash is represented as a commit whose tree records the state of the +working directory, and its first parent is the commit at `HEAD` when +the stash was created. The tree of the second parent records the +state of the index when the stash is made, and it is made a child of +the `HEAD` commit. The ancestry graph looks like this: + + .----W + / / + ...--H----I + +where `H` is the `HEAD` commit, `I` is a commit that records the state +of the index, and `W` is a commit that records the state of the working +tree. + + +EXAMPLES +-------- + +Pulling into a dirty tree:: + +When you are in the middle of something, you learn that there are +upstream changes that are possibly relevant to what you are +doing. When your local changes do not conflict with the changes in +the upstream, a simple `git pull` will let you move forward. ++ +However, there are cases in which your local changes do conflict with +the upstream changes, and `git pull` refuses to overwrite your +changes. In such a case, you can stash your changes away, +perform a pull, and then unstash, like this: ++ +---------------------------------------------------------------- +$ git pull +... +file foobar not up to date, cannot merge. +$ git stash +$ git pull +$ git stash apply +---------------------------------------------------------------- + +Interrupted workflow:: + +When you are in the middle of something, your boss comes in and +demands that you fix something immediately. Traditionally, you would +make a commit to a temporary branch to store your changes away, and +return to your original branch to make the emergency fix, like this: ++ +---------------------------------------------------------------- +... hack hack hack ... +$ git checkout -b my_wip +$ git commit -a -m "WIP" +$ git checkout master +$ edit emergency fix +$ git commit -a -m "Fix in a hurry" +$ git checkout my_wip +$ git reset --soft HEAD^ +... continue hacking ... +---------------------------------------------------------------- ++ +You can use `git-stash` to simplify the above, like this: ++ +---------------------------------------------------------------- +... hack hack hack ... +$ git stash +$ edit emergency fix +$ git commit -a -m "Fix in a hurry" +$ git stash apply +... continue hacking ... +---------------------------------------------------------------- + +SEE ALSO +-------- +gitlink:git-checkout[1], +gitlink:git-commit[1], +gitlink:git-reflog[1], +gitlink:git-reset[1] + +AUTHOR +------ +Written by Nanako Shiraishi + +GIT +--- +Part of the gitlink:git[7] suite diff --git a/git-submodule.html b/git-submodule.html index 5aef21260..b7243732e 100644 --- a/git-submodule.html +++ b/git-submodule.html @@ -272,12 +272,25 @@ git-submodule(1) Manual Page

SYNOPSIS

-

git-submodule [--quiet] [--cached] [status|init|update] [--] [<path>…]

+

git-submodule [--quiet] [-b branch] add <repository> [<path>] +git-submodule [--quiet] [--cached] [status|init|update] [--] [<path>…]

COMMANDS

+add +
+
+

+ Add the given repository as a submodule at the given path + to the changeset to be committed next. In particular, the + repository is cloned at the specified path, added to the + changeset and registered in .gitmodules. If no path is + specified, the path is deduced from the repository specification. +

+
+
status
@@ -326,6 +339,14 @@ update

+-b, --branch +
+
+

+ Branch of repository to add as submodule. +

+
+
--cached
@@ -363,7 +384,7 @@ to each submodule url is "module.$path.url".

diff --git a/git-submodule.txt b/git-submodule.txt index f8fb80f18..7f0904e29 100644 --- a/git-submodule.txt +++ b/git-submodule.txt @@ -8,11 +8,19 @@ git-submodule - Initialize, update or inspect submodules SYNOPSIS -------- +'git-submodule' [--quiet] [-b branch] add [] 'git-submodule' [--quiet] [--cached] [status|init|update] [--] [...] COMMANDS -------- +add:: + Add the given repository as a submodule at the given path + to the changeset to be committed next. In particular, the + repository is cloned at the specified path, added to the + changeset and registered in .gitmodules. If no path is + specified, the path is deduced from the repository specification. + status:: Show the status of the submodules. This will print the SHA-1 of the currently checked out commit for each submodule, along with the @@ -39,6 +47,9 @@ OPTIONS -q, --quiet:: Only print error messages. +-b, --branch:: + Branch of repository to add as submodule. + --cached:: Display the SHA-1 stored in the index, not the SHA-1 of the currently checked out submodule commit. This option is only valid for the diff --git a/git.html b/git.html index 85fd48582..b8f94f3fe 100644 --- a/git.html +++ b/git.html @@ -645,6 +645,14 @@ ancillary user utilities.

+git-stash(1) +
+
+

+ Stash the changes in a dirty working directory away. +

+
+
git-status(1)
@@ -2382,7 +2390,7 @@ contributors on the git-list <git@vger.kernel.org>.

diff --git a/git.txt b/git.txt index 2cc0b214d..10c7bb3f4 100644 --- a/git.txt +++ b/git.txt @@ -42,9 +42,10 @@ unreleased) version of git, that is available from 'master' branch of the `git.git` repository. Documentation for older releases are available here: -* link:v1.5.2.2/git.html[documentation for release 1.5.2.2] +* link:v1.5.2.3/git.html[documentation for release 1.5.2.3] * release notes for + link:RelNotes-1.5.2.3.txt[1.5.2.3], link:RelNotes-1.5.2.2.txt[1.5.2.2], link:RelNotes-1.5.2.1.txt[1.5.2.1], link:RelNotes-1.5.2.txt[1.5.2].