@@ -57,96 +57,96 @@ OPTIONS[[OPTIONS]]
57
57
58
58
<refspec >... ::
59
59
Specify what destination ref to update with what source object.
60
- The format of a <refspec > parameter is an optional plus
61
- `+` , followed by the source object <src >, followed
62
- by a colon `:` , followed by the destination ref <dst >.
63
- +
64
- The <src > is often the name of the branch you would want to push, but
65
- it can be any arbitrary "SHA-1 expression", such as `master~4` or
66
- `HEAD` (see linkgit:gitrevisions[7]).
67
- +
68
- The <dst > tells which ref on the remote side is updated with this
69
- push. Arbitrary expressions cannot be used here, an actual ref must
70
- be named.
71
- If `git push [<repository>]` without any `<refspec>` argument is set to
72
- update some ref at the destination with `<src>` with
73
- `remote.<repository>.push` configuration variable, `:<dst>` part can
74
- be omitted-- such a push will update a ref that `<src>` normally updates
75
- without any `<refspec>` on the command line. Otherwise, missing
76
- `:<dst>` means to update the same ref as the `<src>` .
77
- +
78
- If <dst > doesn't start with `refs/` (e.g. `refs/heads/master` ) we will
79
- try to infer where in `refs/*` on the destination <repository > it
80
- belongs based on the type of <src > being pushed and whether <dst >
81
- is ambiguous.
82
60
+
83
- --
84
- * If <dst > unambiguously refers to a ref on the <repository > remote,
85
- then push to that ref.
86
-
87
- * If <src> resolves to a ref starting with refs/heads/ or refs/tags/,
88
- then prepend that to <dst>.
89
-
90
- * Other ambiguity resolutions might be added in the future, but for
91
- now any other cases will error out with an error indicating what we
92
- tried, and depending on the `advice.pushUnqualifiedRefname`
93
- configuration (see linkgit:git-config[1]) suggest what refs/
94
- namespace you may have wanted to push to.
95
-
96
- --
97
- +
98
- The object referenced by <src > is used to update the <dst > reference
99
- on the remote side. Whether this is allowed depends on where in
100
- `refs/*` the <dst > reference lives as described in detail below, in
101
- those sections "update" means any modifications except deletes, which
102
- as noted after the next few sections are treated differently.
103
- +
104
- The `refs/heads/*` namespace will only accept commit objects, and
105
- updates only if they can be fast-forwarded.
106
- +
107
- The `refs/tags/*` namespace will accept any kind of object (as
108
- commits, trees and blobs can be tagged), and any updates to them will
109
- be rejected.
110
- +
111
- It's possible to push any type of object to any namespace outside of
112
- `refs/{tags,heads}/*` . In the case of tags and commits, these will be
113
- treated as if they were the commits inside `refs/heads/*` for the
114
- purposes of whether the update is allowed.
115
- +
116
- I.e. a fast-forward of commits and tags outside `refs/{tags,heads}/*`
117
- is allowed, even in cases where what's being fast-forwarded is not a
118
- commit, but a tag object which happens to point to a new commit which
119
- is a fast-forward of the commit the last tag (or commit) it's
120
- replacing. Replacing a tag with an entirely different tag is also
121
- allowed, if it points to the same commit, as well as pushing a peeled
122
- tag, i.e. pushing the commit that existing tag object points to, or a
123
- new tag object which an existing commit points to.
124
- +
125
- Tree and blob objects outside of `refs/{tags,heads}/*` will be treated
126
- the same way as if they were inside `refs/tags/*` , any update of them
127
- will be rejected.
128
- +
129
- All of the rules described above about what's not allowed as an update
130
- can be overridden by adding an the optional leading `+` to a refspec
61
+ The format for a refspec is [+]<src >[:<dst >], for example `main` ,
62
+ `main:other` , or `HEAD^:refs/heads/main` .
63
+ +
64
+ The `<src>` is often the name of the local branch to push, but it can be
65
+ any arbitrary "SHA-1 expression" (see linkgit:gitrevisions[7]).
66
+ +
67
+ The `<dst>` determines what to update on the remote side. It must be the
68
+ name of a branch, tag, or other ref, not an arbitrary expression.
69
+ `:<dst>` is optional.
70
+ +
71
+ `+` is optional and does the same thing as `--force` .
72
+ +
73
+ You can write a refspec using the fully expanded form (for
74
+ example `main:refs/heads/main` ) which specifies the exact source
75
+ and destination, or with a shorter form (for example `main` or
76
+ `main:other` ). Here are the rules for how refspecs are expanded,
77
+ as well as various other special refspec forms:
78
+ +
79
+ 1. `<src>` without a `:<dst>` means to update the same ref as the
80
+ `<src>` , unless the `remote.<repository>.push` configuration specifies a
81
+ different <dst >. For example, if `main` is a branch, then the refspec
82
+ `main` expands to `main:refs/heads/main` .
83
+ 2. If <dst > unambiguously refers to a ref on the <repository > remote,
84
+ then expand it to that ref. For example, if `v1.0` is a tag on the
85
+ remote, then `HEAD:v1.0` expands to `HEAD:refs/tags/v1.0` .
86
+ 3. If <src > resolves to a ref starting with refs/heads/ or refs/tags/,
87
+ then prepend that to <dst >. For example, if `main` is a branch, then
88
+ `main:other` expands to `main:refs/heads/other`
89
+ 4. The special refspec `:` (or `+:` to allow non-fast-forward updates)
90
+ directs Git to push "matching" branches: for every branch that exists on
91
+ the local side, the remote side is updated if a branch of the same name
92
+ already exists on the remote side.
93
+ 5. `tag <tag>` expands to `refs/tags/<tag>:refs/tags/<tag>` .
94
+ 6. <src > may contain a * to indicate a simple pattern match.
95
+ This works like a glob that matches any ref matching the pattern.
96
+ There must be only one * in both the <src > and <dst >.
97
+ It will map refs to the destination by replacing the * with the
98
+ contents matched from the source. For example, `refs/heads/*:refs/heads/*`
99
+ will push all branches.
100
+ 7. A refspec starting with ^ is a negative refspec.
101
+ This specifies refs to exclude. A ref will be considered to
102
+ match if it matches at least one positive refspec, and does not
103
+ match any negative refspec. Negative refspecs can be pattern refspecs.
104
+ They must only contain a <src >.
105
+ Fully spelled out hex object names are also not supported.
106
+ For example, `git push origin 'refs/heads/*' '^refs/heads/dev-*'`
107
+ will push all branches except for those starting with `dev-`
108
+ 8. If `<src>` is empty, it deletes the <dst > ref from the remote
109
+ repository. For example, `git push origin :dev` will
110
+ delete the `dev` branch.
111
+ Deletions are always accepted without a leading `+` in the
112
+ refspec (or `--force` ), except when forbidden by configuration or hooks.
113
+ See `receive.denyDeletes` in linkgit:git-config[1] and `pre-receive` and
114
+ `update` in linkgit:githooks[5].
115
+ 9. If the refspec can't be expanded unambiguously, error
116
+ out with an error indicating what was
117
+ tried, and depending on the `advice.pushUnqualifiedRefname`
118
+ configuration (see linkgit:git-config[1]) suggest what refs/
119
+ namespace you may have wanted to push to.
120
+
121
+ +
122
+ Not all updates are allowed: it depends on what kind of destination
123
+ you're pushing to. In the following rules "update" means any
124
+ modifications except deletes, which as noted above are treated differently.
125
+ +
126
+ All of these rules
127
+ can be overridden by adding the optional leading `+` to a refspec
131
128
(or using `--force` command line option). The only exception to this
132
129
is that no amount of forcing will make the `refs/heads/*` namespace
133
130
accept a non-commit object. Hooks and configuration can also override
134
131
or amend these rules, see e.g. `receive.denyNonFastForwards` in
135
132
linkgit:git-config[1] and `pre-receive` and `update` in
136
133
linkgit:githooks[5].
137
134
+
138
- Pushing an empty <src > allows you to delete the <dst > ref from the
139
- remote repository. Deletions are always accepted without a leading `+`
140
- in the refspec (or `--force` ), except when forbidden by configuration
141
- or hooks. See `receive.denyDeletes` in linkgit:git-config[1] and
142
- `pre-receive` and `update` in linkgit:githooks[5].
143
- +
144
- The special refspec `:` (or `+:` to allow non-fast-forward updates)
145
- directs Git to push "matching" branches: for every branch that exists on
146
- the local side, the remote side is updated if a branch of the same name
147
- already exists on the remote side.
148
- +
149
- `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>` .
135
+ 1. If the destination is a **branch** (`refs/heads/*` ): the source must
136
+ be a commit object, and only fast-forward updates are allowed.
137
+ 2. If the destination is a **tag** (`refs/tags/*` ): the source can
138
+ be any object (as commits, trees and blobs can be tagged), and any
139
+ updates to them will be rejected.
140
+ 3. For destinations outside of `refs/{tags,heads}/*` :
141
+ * If the source is a tree or blob object, any updates will be rejected
142
+ * If the source is a tag or commit object, any fast-forward update
143
+ is allowed, even in cases where what's being fast-forwarded is not a
144
+ commit, but a tag object which happens to point to a new commit which
145
+ is a fast-forward of the commit the last tag (or commit) it's
146
+ replacing. Replacing a tag with an entirely different tag is also
147
+ allowed, if it points to the same commit, as well as pushing a peeled
148
+ tag, i.e. pushing the commit that existing tag object points to, or a
149
+ new tag object which an existing commit points to.
150
150
151
151
-- all::
152
152
-- branches::
0 commit comments