~ubuntu-branches/ubuntu/intrepid/git-core/intrepid-updates

« back to all changes in this revision

Viewing changes to Documentation/git-pull.txt

  • Committer: Package Import Robot
  • Author(s): Gerrit Pape
  • Date: 2007-04-22 13:31:05 UTC
  • mfrom: (1.1.14)
  • Revision ID: package-import@ubuntu.com-20070422133105-tkmhz328g2p0epz1
Tags: 1:1.5.1.2-1
* new upstream point release.
* debian/changelog.upstream: upstream changes taken from mailing list
  announcement.

Show diffs side-by-side

added added

removed removed

Lines of Context:
3
3
 
4
4
NAME
5
5
----
6
 
git-pull - Pull and merge from another repository or a local branch
 
6
git-pull - Fetch from and merge with another repository or a local branch
7
7
 
8
8
 
9
9
SYNOPSIS
33
33
 
34
34
include::merge-strategies.txt[]
35
35
 
 
36
DEFAULT BEHAVIOUR
 
37
-----------------
 
38
 
 
39
Often people use `git pull` without giving any parameter.
 
40
Traditionally, this has been equivalent to saying `git pull
 
41
origin`.  However, when configuration `branch.<name>.remote` is
 
42
present while on branch `<name>`, that value is used instead of
 
43
`origin`.
 
44
 
 
45
In order to determine what URL to use to fetch from, the value
 
46
of the configuration `remote.<origin>.url` is consulted
 
47
and if there is not any such variable, the value on `URL: ` line
 
48
in `$GIT_DIR/remotes/<origin>` file is used.
 
49
 
 
50
In order to determine what remote branches to fetch (and
 
51
optionally store in the tracking branches) when the command is
 
52
run without any refspec parameters on the command line, values
 
53
of the configuration variable `remote.<origin>.fetch` are
 
54
consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>`
 
55
file is consulted and its `Pull: ` lines are used.
 
56
In addition to the refspec formats described in the OPTIONS
 
57
section, you can have a globbing refspec that looks like this:
 
58
 
 
59
------------
 
60
refs/heads/*:refs/remotes/origin/*
 
61
------------
 
62
 
 
63
A globbing refspec must have a non-empty RHS (i.e. must store
 
64
what were fetched in tracking branches), and its LHS and RHS
 
65
must end with `/*`.  The above specifies that all remote
 
66
branches are tracked using tracking branches in
 
67
`refs/remotes/origin/` hierarchy under the same name.
 
68
 
 
69
The rule to determine which remote branch to merge after
 
70
fetching is a bit involved, in order not to break backward
 
71
compatibility.
 
72
 
 
73
If explicit refspecs were given on the command
 
74
line of `git pull`, they are all merged.
 
75
 
 
76
When no refspec was given on the command line, then `git pull`
 
77
uses the refspec from the configuration or
 
78
`$GIT_DIR/remotes/<origin>`.  In such cases, the following
 
79
rules apply:
 
80
 
 
81
. If `branch.<name>.merge` configuration for the current
 
82
  branch `<name>` exists, that is the name of the branch at the
 
83
  remote site that is merged.
 
84
 
 
85
. If the refspec is a globbing one, nothing is merged.
 
86
 
 
87
. Otherwise the remote branch of the first refspec is merged.
 
88
 
 
89
 
36
90
EXAMPLES
37
91
--------
38
92
 
39
93
git pull, git pull origin::
40
 
        Fetch the default head from the repository you cloned
41
 
        from and merge it into your current branch.
 
94
        Update the remote-tracking branches for the repository
 
95
        you cloned from, then merge one of them into your
 
96
        current branch.  Normally the branch merged in is
 
97
        the HEAD of the remote repository, but the choice is
 
98
        determined by the branch.<name>.remote and
 
99
        branch.<name>.merge options; see gitlink:git-config[1]
 
100
        for details.
 
101
 
 
102
git pull origin next::
 
103
        Merge into the current branch the remote branch `next`;
 
104
        leaves a copy of `next` temporarily in FETCH_HEAD, but
 
105
        does not update any remote-tracking branches.
 
106
 
 
107
git pull . fixes enhancements::
 
108
        Bundle local branch `fixes` and `enhancements` on top of
 
109
        the current branch, making an Octopus merge.  This `git pull .`
 
110
        syntax is equivalent to `git merge`.
42
111
 
43
112
git pull -s ours . obsolete::
44
113
        Merge local branch `obsolete` into the current branch,
45
114
        using `ours` merge strategy.
46
115
 
47
 
git pull . fixes enhancements::
48
 
        Bundle local branch `fixes` and `enhancements` on top of
49
 
        the current branch, making an Octopus merge.
50
 
 
51
116
git pull --no-commit . maint::
52
117
        Merge local branch `maint` into the current branch, but
53
118
        do not make a commit automatically.  This can be used
61
126
Command line pull of multiple branches from one repository::
62
127
+
63
128
------------------------------------------------
64
 
$ cat .git/remotes/origin
65
 
URL: git://git.kernel.org/pub/scm/git/git.git
66
 
Pull: master:origin
67
 
 
68
 
$ git checkout master
69
 
$ git fetch origin master:origin +pu:pu maint:maint
70
 
$ git pull . origin
71
 
------------------------------------------------
72
 
+
73
 
Here, a typical `.git/remotes/origin` file from a
74
 
`git-clone` operation is used in combination with
75
 
command line options to `git-fetch` to first update
76
 
multiple branches of the local repository and then
77
 
to merge the remote `origin` branch into the local
78
 
`master` branch.  The local `pu` branch is updated
79
 
even if it does not result in a fast forward update.
80
 
Here, the pull can obtain its objects from the local
81
 
repository using `.`, as the previous `git-fetch` is
82
 
known to have already obtained and made available
83
 
all the necessary objects.
84
 
 
85
 
 
86
 
Pull of multiple branches from one repository using `.git/remotes` file::
87
 
+
88
 
------------------------------------------------
89
 
$ cat .git/remotes/origin
90
 
URL: git://git.kernel.org/pub/scm/git/git.git
91
 
Pull: master:origin
92
 
Pull: +pu:pu
93
 
Pull: maint:maint
94
 
 
95
 
$ git checkout master
96
 
$ git pull origin
97
 
------------------------------------------------
98
 
+
99
 
Here, a typical `.git/remotes/origin` file from a
100
 
`git-clone` operation has been hand-modified to include
101
 
the branch-mapping of additional remote and local
102
 
heads directly.  A single `git-pull` operation while
103
 
in the `master` branch will fetch multiple heads and
104
 
merge the remote `origin` head into the current,
105
 
local `master` branch.
 
129
$ git checkout master
 
130
$ git fetch origin +pu:pu maint:tmp
 
131
$ git pull . tmp
 
132
------------------------------------------------
 
133
+
 
134
This updates (or creates, as necessary) branches `pu` and `tmp`
 
135
in the local repository by fetching from the branches
 
136
(respectively) `pu` and `maint` from the remote repository.
 
137
+
 
138
The `pu` branch will be updated even if it is does not
 
139
fast-forward; the others will not be.
 
140
+
 
141
The final command then merges the newly fetched `tmp` into master.
106
142
 
107
143
 
108
144
If you tried a pull which resulted in a complex conflicts and
112
148
 
113
149
SEE ALSO
114
150
--------
115
 
gitlink:git-fetch[1], gitlink:git-merge[1]
 
151
gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-config[1]
116
152
 
117
153
 
118
154
Author