diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/git-clone.txt | 27 | ||||
| -rw-r--r-- | Documentation/git-http-push.txt | 89 | ||||
| -rw-r--r-- | Documentation/git-merge.txt | 2 | ||||
| -rw-r--r-- | Documentation/git-pull.txt | 36 | ||||
| -rwxr-xr-x | Documentation/install-webdoc.sh | 4 | ||||
| -rw-r--r-- | Documentation/merge-strategies.txt | 35 | ||||
| -rw-r--r-- | Documentation/pull-fetch-param.txt | 21 |
7 files changed, 163 insertions, 51 deletions
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index dd92cdefc2..fefd2985f3 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -12,7 +12,22 @@ SYNOPSIS DESCRIPTION ----------- -Clones a repository into a newly created directory. +Clones a repository into a newly created directory. All remote +branch heads are copied under `$GIT_DIR/refs/heads/`, except +that the remote `master` is also copied to `origin` branch. + +In addition, `$GIT_DIR/remotes/origin` file is set up to have +this line: + + Pull: master:origin + +This is to help the typical workflow of working off of the +remote `master` branch. Every time `git pull` without argument +is run, the progress on the remote `master` branch is tracked by +copying it into the local `origin` branch, and merged into the +branch you are currently working on. Remote branches other than +`master` are also added there to be tracked. + OPTIONS ------- @@ -28,9 +43,10 @@ OPTIONS --shared:: -s:: When the repository to clone is on the local machine, - instead of using hard links automatically setup + instead of using hard links, automatically setup .git/objects/info/alternatives to share the objects - with the source repository + with the source repository. The resulting repository + starts out without any object of its own. --quiet:: -q:: @@ -49,14 +65,13 @@ OPTIONS <repository>:: The (possibly remote) repository to clone from. It can - be an "rsync://host/dir" URL, an "http://host/dir" URL, - or [<host>:]/dir notation that is used by 'git-clone-pack'. - Currently http transport is not supported. + be any URL git-fetch supports. <directory>:: The name of a new directory to be cloned into. It is an error to specify an existing directory. + Author ------ Written by Linus Torvalds <torvalds@osdl.org> diff --git a/Documentation/git-http-push.txt b/Documentation/git-http-push.txt new file mode 100644 index 0000000000..c7066d66f3 --- /dev/null +++ b/Documentation/git-http-push.txt @@ -0,0 +1,89 @@ +git-http-push(1) +================ + +NAME +---- +git-http-push - Push missing objects using HTTP/DAV. + + +SYNOPSIS +-------- +'git-http-push' [--complete] [--force] [--verbose] <url> <ref> [<ref>...] + +DESCRIPTION +----------- +Sends missing objects to remote repository, and updates the +remote branch. + + +OPTIONS +------- +--complete:: + Do not assume that the remote repository is complete in its + current state, and verify all objects in the entire local + ref's history exist in the remote repository. + +--force:: + Usually, the command refuses to update a remote ref that + is not an ancestor of the local ref used to overwrite it. + This flag disables the check. What this means is that + the remote repository can lose commits; use it with + care. + +--verbose:: + Report the list of objects being walked locally and the + list of objects successfully sent to the remote repository. + +<ref>...: + The remote refs to update. + + +Specifying the Refs +------------------- + +A '<ref>' specification can be either a single pattern, or a pair +of such patterns separated by a colon ":" (this means that a ref name +cannot have a colon in it). A single pattern '<name>' is just a +shorthand for '<name>:<name>'. + +Each pattern pair consists of the source side (before the colon) +and the destination side (after the colon). The ref to be +pushed is determined by finding a match that matches the source +side, and where it is pushed is determined by using the +destination side. + + - It is an error if <src> does not match exactly one of the + local refs. + + - If <dst> does not match any remote ref, either + + * it has to start with "refs/"; <dst> is used as the + destination literally in this case. + + * <src> == <dst> and the ref that matched the <src> must not + exist in the set of remote refs; the ref matched <src> + locally is used as the name of the destination. + +Without '--force', the <src> ref is stored at the remote only if +<dst> does not exist, or <dst> is a proper subset (i.e. an +ancestor) of <src>. This check, known as "fast forward check", +is performed in order to avoid accidentally overwriting the +remote ref and lose other peoples' commits from there. + +With '--force', the fast forward check is disabled for all refs. + +Optionally, a <ref> parameter can be prefixed with a plus '+' sign +to disable the fast-forward check only on that ref. + + +Author +------ +Written by Nick Hengeveld <nickh@reactrix.com> + +Documentation +-------------- +Documentation by Nick Hengeveld + +GIT +--- +Part of the gitlink:git[7] suite diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index 3e058db996..b3ef19bae4 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -34,6 +34,8 @@ include::merge-pull-opts.txt[] least one <remote>. Specifying more than one <remote> obviously means you are trying an Octopus. +include::merge-strategies.txt[] + SEE ALSO -------- diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index ec10a2f409..7ebb08da0c 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -31,42 +31,8 @@ include::pull-fetch-param.txt[] include::merge-pull-opts.txt[] +include::merge-strategies.txt[] -MERGE STRATEGIES ----------------- - -resolve:: - This can only resolve two heads (i.e. the current branch - and another branch you pulled from) using 3-way merge - algorithm. It tries to carefully detect criss-cross - merge ambiguities and is considered generally safe and - fast. This is the default merge strategy when pulling - one branch. - -recursive:: - This can only resolve two heads using 3-way merge - algorithm. When there are more than one common - ancestors that can be used for 3-way merge, it creates a - merged tree of the common ancestores and uses that as - the reference tree for the 3-way merge. This has been - reported to result in fewer merge conflicts without - causing mis-merges by tests done on actual merge commits - taken from Linux 2.6 kernel development history. - Additionally this can detect and handle merges involving - renames. - -octopus:: - This resolves more than two-head case, but refuses to do - complex merge that needs manual resolution. It is - primarily meant to be used for bundling topic branch - heads together. This is the default merge strategy when - pulling more than one branch. - -ours:: - This resolves any number of heads, but the result of the - merge is always the current branch head. It is meant to - be used to supersede old development history of side - branches. EXAMPLES diff --git a/Documentation/install-webdoc.sh b/Documentation/install-webdoc.sh index d593ab988b..50638c78d5 100755 --- a/Documentation/install-webdoc.sh +++ b/Documentation/install-webdoc.sh @@ -2,7 +2,7 @@ T="$1" -for h in *.html howto/*.txt howto/*.html +for h in *.html *.txt howto/*.txt howto/*.html do diff -u -I'Last updated [0-9][0-9]-[A-Z][a-z][a-z]-' "$T/$h" "$h" || { echo >&2 "# install $h $T/$h" @@ -12,7 +12,7 @@ do } done strip_leading=`echo "$T/" | sed -e 's|.|.|g'` -for th in "$T"/*.html "$T"/howto/*.txt "$T"/howto/*.html +for th in "$T"/*.html "$T"/*.txt "$T"/howto/*.txt "$T"/howto/*.html do h=`expr "$th" : "$strip_leading"'\(.*\)'` case "$h" in diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt new file mode 100644 index 0000000000..3ec56d22eb --- /dev/null +++ b/Documentation/merge-strategies.txt @@ -0,0 +1,35 @@ +MERGE STRATEGIES +---------------- + +resolve:: + This can only resolve two heads (i.e. the current branch + and another branch you pulled from) using 3-way merge + algorithm. It tries to carefully detect criss-cross + merge ambiguities and is considered generally safe and + fast. This is the default merge strategy when pulling + one branch. + +recursive:: + This can only resolve two heads using 3-way merge + algorithm. When there are more than one common + ancestors that can be used for 3-way merge, it creates a + merged tree of the common ancestores and uses that as + the reference tree for the 3-way merge. This has been + reported to result in fewer merge conflicts without + causing mis-merges by tests done on actual merge commits + taken from Linux 2.6 kernel development history. + Additionally this can detect and handle merges involving + renames. + +octopus:: + This resolves more than two-head case, but refuses to do + complex merge that needs manual resolution. It is + primarily meant to be used for bundling topic branch + heads together. This is the default merge strategy when + pulling more than one branch. + +ours:: + This resolves any number of heads, but the result of the + merge is always the current branch head. It is meant to + be used to supersede old development history of side + branches. diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt index 57e9ddf0d6..5c2888e163 100644 --- a/Documentation/pull-fetch-param.txt +++ b/Documentation/pull-fetch-param.txt @@ -82,14 +82,19 @@ must know this is the expected usage pattern for a branch. [NOTE] You never do your own development on branches that appear on the right hand side of a <refspec> colon on `Pull:` lines; -they are to be updated by `git-fetch`. The corollary is that -a local branch should be introduced and named on a <refspec> -right-hand-side if you intend to do development derived from -that branch. -This leads to the common `Pull: master:origin` mapping of a -remote `master` branch to a local `origin` branch, which -is then merged to a local development branch, again typically -named `master`. +they are to be updated by `git-fetch`. If you intend to do +development derived from a remote branch `B`, have a `Pull:` +line to track it (i.e. `Pull: B:remote-B`), and have a separate +branch `my-B` to do your development on top of it. The latter +is created by `git branch my-B remote-B` (or its equivalent `git +checkout -b my-B remote-B`). Run `git fetch` to keep track of +the progress of the remote side, and when you see something new +on the remote branch, merge it into your development branch with +`git pull . remote-B`, while you are on `my-B` branch. +The common `Pull: master:origin` mapping of a remote `master` +branch to a local `origin` branch, which is then merged to a +ocal development branch, again typically named `master`, is made +when you run `git clone` for you to follow this pattern. + [NOTE] There is a difference between listing multiple <refspec> |