diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/diff-options.txt | 8 | ||||
| -rw-r--r-- | Documentation/everyday.txt | 41 | ||||
| -rw-r--r-- | Documentation/git-archimport.txt | 23 | ||||
| -rw-r--r-- | Documentation/git-check-ref-format.txt | 8 | ||||
| -rw-r--r-- | Documentation/git-clone-pack.txt | 6 | ||||
| -rw-r--r-- | Documentation/git-commit.txt | 4 | ||||
| -rw-r--r-- | Documentation/git-fetch-pack.txt | 7 | ||||
| -rw-r--r-- | Documentation/git-merge.txt | 5 | ||||
| -rw-r--r-- | Documentation/git-octopus.txt | 38 | ||||
| -rw-r--r-- | Documentation/git-pull.txt | 5 | ||||
| -rw-r--r-- | Documentation/git-reset.txt | 33 | ||||
| -rw-r--r-- | Documentation/git-update-server-info.txt | 6 | ||||
| -rw-r--r-- | Documentation/git.txt | 3 | ||||
| -rw-r--r-- | Documentation/hooks.txt | 8 | ||||
| -rw-r--r-- | Documentation/howto/rebuild-from-update-hook.txt | 8 | ||||
| -rw-r--r-- | Documentation/howto/using-topic-branches.txt | 5 | ||||
| -rw-r--r-- | Documentation/tutorial.txt | 28 |
17 files changed, 160 insertions, 76 deletions
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 6b496ede25..9e574a04d3 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -18,6 +18,14 @@ object name of pre- and post-image blob on the "index" line when generating a patch format output. +--abbrev[=<n>]:: + Instead of showing the full 40-byte hexadecimal object + name in diff-raw format output and diff-tree header + lines, show only handful dhexigits prefix. This is + independent of --full-index option above, which controls + the diff-patch output format. Non default number of + digits can be specified with --abbrev=<n>. + -B:: Break complete rewrite changes into pairs of delete and create. diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index d8d7a6441a..3ab9b916c2 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -211,10 +211,12 @@ $ git fetch --tags <8> <1> repeat as needed. <2> extract patches from your branch for e-mail submission. -<3> "pull" fetches from "origin" by default and merges. -<4> look at the changes since last time we checked, only in the +<3> "pull" fetches from "origin" by default and merges into the +current branch. +<4> immediately after pulling, look at the changes done upstream +since last time we checked, only in the area we are interested in. -<5> fetch from a specific branch from a specific repository and and merge. +<5> fetch from a specific branch from a specific repository and merge. <6> revert the pull. <7> garbage collect leftover objects from reverted pull. <8> from time to time, obtain official tags from the "origin" @@ -330,16 +332,18 @@ master, nor exposed as a part of a stable branch. <8> and bundle topic branches still cooking. <9> backport a critical fix. <10> create a signed tag. -<11> make sure I did not accidentally rewound master beyond what I +<11> make sure I did not accidentally rewind master beyond what I already pushed out. "ko" shorthand points at the repository I have at kernel.org, and looks like this: -$ cat .git/remotes/ko -URL: kernel.org:/pub/scm/git/git.git -Pull: master:refs/tags/ko-master -Pull: maint:refs/tags/ko-maint -Push: master -Push: +pu -Push: maint + $ cat .git/remotes/ko + URL: kernel.org:/pub/scm/git/git.git + Pull: master:refs/tags/ko-master + Pull: maint:refs/tags/ko-maint + Push: master + Push: +pu + Push: maint +In the output from "git show-branch", "master" should have +everything "ko-master" has. <12> push out the bleeding edge. <13> push the tag out, too. ------------ @@ -357,8 +361,8 @@ and maintain access to the repository by developers. * gitlink:git-shell[1] can be used as a 'restricted login shell' for shared central repository users. - * link:howto/update-hook-example.txt[update hook howto] has a - good example of managing a shared central repository. +link:howto/update-hook-example.txt[update hook howto] has a good +example of managing a shared central repository. Examples @@ -424,3 +428,14 @@ for branch policy control. david is the release manager and is the only person who can create and push version tags. ------------ + +HTTP server to support dumb protocol transfer.:: ++ +------------ +dev$ git update-server-info <1> +dev$ ftp user@isp.example.com <2> +ftp> cp -r .git /home/user/myproject.git + +<1> make sure your info/refs and objects/info/packs are up-to-date +<2> upload to public HTTP server hosted by your ISP. +------------ diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt index fcda0125af..a2bd788f37 100644 --- a/Documentation/git-archimport.txt +++ b/Documentation/git-archimport.txt @@ -8,7 +8,8 @@ git-archimport - Import an Arch repository into git SYNOPSIS -------- -`git-archimport` [ -h ] [ -v ] [ -T ] [ -t tempdir ] +`git-archimport` [ -h ] [ -v ] [ -o ] [ -a ] [ -f ] [ -T ] + [ -D depth ] [ -t tempdir ] <archive/branch> [ <archive/branch> ] DESCRIPTION @@ -63,6 +64,26 @@ OPTIONS Many tags. Will create a tag for every commit, reflecting the commit name in the Arch repository. +-f:: + Use the fast patchset import strategy. This can be significantly + faster for large trees, but cannot handle directory renames or + permissions changes. The default strategy is slow and safe. + +-o:: + Use this for compatibility with old-style branch names used by + earlier versions of git-archimport. Old-style branch names + were category--branch, whereas new-style branch names are + archive,category--branch--version. + +-D <depth>:: + Follow merge ancestry and attempt to import trees that have been + merged from. Specify a depth greater than 1 if patch logs have been + pruned. + +-a:: + Attempt to auto-register archives at http://mirrors.sourcecontrol.net + This is particularly useful with the -D option. + -t <tmpdir>:: Override the default tempdir. diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index 636e9516b0..f7f84c644e 100644 --- a/Documentation/git-check-ref-format.txt +++ b/Documentation/git-check-ref-format.txt @@ -26,13 +26,15 @@ imposes the following rules on how refs are named: . It cannot have ASCII control character (i.e. bytes whose values are lower than \040, or \177 `DEL`), space, tilde `~`, - caret `{caret}`, or colon `:` anywhere; + caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`, + or open bracket `[` anywhere; . It cannot end with a slash `/`. These rules makes it easy for shell script based tools to parse -refnames, and also avoids ambiguities in certain refname -expressions (see gitlink:git-rev-parse[1]). Namely: +refnames, pathname expansion by the shell when a refname is used +unquoted (by mistake), and also avoids ambiguities in certain +refname expressions (see gitlink:git-rev-parse[1]). Namely: . double-dot `..` are often used as in `ref1..ref2`, and in some context this notation means `{caret}ref1 ref2` (i.e. not in diff --git a/Documentation/git-clone-pack.txt b/Documentation/git-clone-pack.txt index cfc7b62f31..39906fc450 100644 --- a/Documentation/git-clone-pack.txt +++ b/Documentation/git-clone-pack.txt @@ -43,7 +43,11 @@ OPTIONS The heads to update. This is relative to $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When unspecified, all heads are updated to match the remote repository. - ++ +Usually all the refs from existing repository are stored +under the same name in the new repository. Giving explicit +<head> arguments instead writes the object names and refs to +the standard output, just like get-fetch-pack does. Author ------ diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index b92cf48315..8b91f221fe 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -66,6 +66,10 @@ OPTIONS Update specified paths in the index file before committing. +If you make a commit and then found a mistake immediately after +that, you can recover from it with gitlink:git-reset[1]. + + Author ------ Written by Linus Torvalds <torvalds@osdl.org> and diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index ea6faab059..b507e9b648 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -8,7 +8,7 @@ git-fetch-pack - Receive missing objects from another repository. SYNOPSIS -------- -git-fetch-pack [-q] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...] +git-fetch-pack [-q] [-k] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...] DESCRIPTION ----------- @@ -29,6 +29,11 @@ OPTIONS Pass '-q' flag to 'git-unpack-objects'; this makes the cloning process less verbose. +-k:: + Do not invoke 'git-unpack-objects' on received data, but + create a single packfile out of it instead, and store it + in the object database. + --exec=<git-upload-pack>:: Use this to specify the path to 'git-upload-pack' on the remote side, if is not found on your $PATH. diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 0cac563d40..4ce799b520 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -37,6 +37,11 @@ include::merge-options.txt[] include::merge-strategies.txt[] +If you tried a merge which resulted in a complex conflicts and +would want to start over, you can recover with +gitlink:git-reset[1]. + + HOW MERGE WORKS --------------- diff --git a/Documentation/git-octopus.txt b/Documentation/git-octopus.txt deleted file mode 100644 index 6e32ea347c..0000000000 --- a/Documentation/git-octopus.txt +++ /dev/null @@ -1,38 +0,0 @@ -git-octopus(1) -============== - -NAME ----- -git-octopus - Merge more than two commits. - - -SYNOPSIS --------- -'git-octopus' - -DESCRIPTION ------------ -After running 'git fetch', $GIT_DIR/FETCH_HEAD contains the -following information, one line per remote ref: - ------------------------------------------------- -<object name> <ref name> from <repository> ------------------------------------------------- - -Using this information, create and commit an Octopus merge on -top of the current HEAD. - - -Author ------- -Written by Junio C Hamano <junkio@cox.net> - - -Documentation --------------- -Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. - -GIT ---- -Part of the gitlink:git[7] suite - diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index c65ca9a530..3a7d385225 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -104,6 +104,11 @@ merge the remote `origin` head into the current, local `master` branch. +If you tried a pull which resulted in a complex conflicts and +would want to start over, you can recover with +gitlink:git-reset[1]. + + SEE ALSO -------- gitlink:git-fetch[1], gitlink:git-merge[1] diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index 02048918bf..c6a269b7ef 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt @@ -111,6 +111,39 @@ remain there. changes still in the working tree. ------------ +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 +$ git reset --hard <2> + +<1> try to update from the upstream resulted in a lot of +conflicts; you were not ready to spend a lot of time merging +right now, so you decide to do that later. +<2> "pull" has not made merge commit, so "git reset --hard" +which is a synonym for "git reset --hard HEAD" clears the mess +from the index file and the working tree. + +$ git pull . topic/branch <3> +Updating from 41223... to 13134... +Fast forward +$ git reset --hard ORIG_HEAD <4> + +<3> merge a topic branch into the current branch, which resulted +in a fast forward. +<4> but you decided that the topic branch is not ready for public +consumption yet. "pull" or "merge" always leaves the original +tip of the current branch in ORIG_HEAD, so resetting hard to it +brings your index file and the working tree back to that state, +and resets the tip of the branch to that commit. +------------ Author ------ diff --git a/Documentation/git-update-server-info.txt b/Documentation/git-update-server-info.txt index 527fb303eb..88a03c7c5e 100644 --- a/Documentation/git-update-server-info.txt +++ b/Documentation/git-update-server-info.txt @@ -12,11 +12,11 @@ SYNOPSIS DESCRIPTION ----------- -A dumb server that does not do on-the-fly pack generations can +A dumb server that does not do on-the-fly pack generations must have some auxiliary information files in $GIT_DIR/info and $GIT_OBJECT_DIRECTORY/info directories to help clients discover -what references and packs the server has and make optimized -pull decisions. This command generates such auxiliary files. +what references and packs the server has. This command +generates such auxiliary files. OPTIONS diff --git a/Documentation/git.txt b/Documentation/git.txt index 482eba7eba..5f068c2a1a 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -297,9 +297,6 @@ gitlink:git-merge[1]:: gitlink:git-mv[1]:: Move or rename a file, a directory, or a symlink. -gitlink:git-octopus[1]:: - Merge more than two commits. - gitlink:git-pull[1]:: Fetch from and merge with a remote repository. diff --git a/Documentation/hooks.txt b/Documentation/hooks.txt index 7ee3571bc0..4ad1920ec1 100644 --- a/Documentation/hooks.txt +++ b/Documentation/hooks.txt @@ -111,6 +111,10 @@ Another use suggested on the mailing list is to use this hook to implement access control which is finer grained than the one based on filesystem group. +The standard output of this hook is sent to /dev/null; if you +want to report something to the git-send-pack on the other end, +you can redirect your output to your stderr. + post-update ----------- @@ -125,3 +129,7 @@ the outcome of `git-receive-pack`. The default post-update hook, when enabled, runs `git-update-server-info` to keep the information used by dumb transport up-to-date. + +The standard output of this hook is sent to /dev/null; if you +want to report something to the git-send-pack on the other end, +you can redirect your output to your stderr. diff --git a/Documentation/howto/rebuild-from-update-hook.txt b/Documentation/howto/rebuild-from-update-hook.txt index ebd025db85..02621b54a0 100644 --- a/Documentation/howto/rebuild-from-update-hook.txt +++ b/Documentation/howto/rebuild-from-update-hook.txt @@ -10,7 +10,7 @@ The pages under http://www.kernel.org/pub/software/scm/git/docs/ are built from Documentation/ directory of the git.git project and needed to be kept up-to-date. The www.kernel.org/ servers are mirrored and I was told that the origin of the mirror is on -the machine master.kernel.org, on which I was given an account +the machine $some.kernel.org, on which I was given an account when I took over git maintainership from Linus. The directories relevant to this how-to are these two: @@ -63,7 +63,7 @@ like this: EOF $ chmod +x /pub/scm/git/git.git/hooks/post-update -There are three things worth mentioning: +There are four things worth mentioning: - The update-hook is run after the repository accepts a "git push", under my user privilege. It is given the full names @@ -77,6 +77,10 @@ There are three things worth mentioning: pull" it does into $HOME/doc-git/docgen/ repository would not work correctly. + - The stdout of update hook script is not connected to git + push; I run the heavy part of the command inside "at", to + receive the execution report via e-mail. + - This is still crude and does not protect against simultaneous make invocations stomping on each other. I would need to add some locking mechanism for this. diff --git a/Documentation/howto/using-topic-branches.txt b/Documentation/howto/using-topic-branches.txt index 494429738f..b3d592fc3e 100644 --- a/Documentation/howto/using-topic-branches.txt +++ b/Documentation/howto/using-topic-branches.txt @@ -42,8 +42,7 @@ So here is the step-by-step guide how this all works for me. First create your work tree by cloning Linus's public tree: - $ git clone \ - master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work + $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work Change directory into the cloned tree you just created @@ -53,7 +52,7 @@ Set up a remotes file so that you can fetch the latest from Linus' master branch into a local branch named "linus": $ cat > .git/remotes/linus - URL: master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Pull: master:linus ^D diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt index a61b824443..3a5c56e24e 100644 --- a/Documentation/tutorial.txt +++ b/Documentation/tutorial.txt @@ -27,6 +27,12 @@ SCM, you can skip them during your first pass. [NOTE] And those "too deep" descriptions are often marked as Note. +[NOTE] +If you are already familiar with another version control system, +like CVS, you may want to take a look at +link:everyday.html[Everyday GIT in 20 commands or so] first +before reading this. + Creating a git repository ------------------------- @@ -1085,9 +1091,10 @@ lacks and transfers (close to) minimum set of objects. HTTP(S):: `http://remote.machine/path/to/repo.git/` + -HTTP and HTTPS transport are used only for downloading. They -first obtain the topmost commit object name from the remote site -by looking at `repo.git/info/refs` file, tries to obtain the +Downloader from http and https URL +first obtains the topmost commit object name from the remote site +by looking at the specified refname under `repo.git/refs/` directory, +and then tries to obtain the commit object by downloading from `repo.git/objects/xx/xxx\...` using the object name of that commit object. Then it reads the commit object to find out its parent commits and the associate @@ -1098,7 +1105,9 @@ sometimes also called 'commit walkers'. The 'commit walkers' are sometimes also called 'dumb transports', because they do not require any git aware smart server like git Native transport does. Any stock HTTP server -would suffice. +that does not even support directory index would suffice. But +you must prepare your repository with `git-update-server-info` +to help dumb transport downloaders. + There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload` programs, which are 'commit walkers'; they outlived their @@ -1511,12 +1520,13 @@ A recommended workflow for a "project lead" goes like this: 2. Prepare a public repository accessible to others. + If other people are pulling from your repository over dumb -transport protocols, you need to keep this repository 'dumb -transport friendly'. After `git init-db`, +transport protocols (HTTP), you need to keep this repository +'dumb transport friendly'. After `git init-db`, `$GIT_DIR/hooks/post-update` copied from the standard templates would contain a call to `git-update-server-info` but the `post-update` hook itself is disabled by default -- enable it -with `chmod +x post-update`. +with `chmod +x post-update`. This makes sure `git-update-server-info` +keeps the necessary files up-to-date. 3. Push into the public repository from your primary repository. @@ -1615,7 +1625,9 @@ cooperation you are probably more familiar with as well. For this, set up a public repository on a machine that is reachable via SSH by people with "commit privileges". Put the committers in the same user group and make the repository -writable by that group. +writable by that group. Make sure their umasks are set up to +allow group members to write into directories other members +have created. You, as an individual committer, then: |