Skip to content

Commit 30a8f63

Browse files
committed
doc: git-push: rewrite refspec specification
- Originally it said that a refspec was `+<src>:<dst>`, but then later contradicted itself by saying that the `:<dst>` is optional. Mention that `:<dst>` is optional much earlier. - Put the complex sets of rules about different refspec forms in lists instead of in long paragraphs of prose - Add examples for the various types of refspecs (negative, deletion, pattern, etc) - Previously `*` and `^` were not mentioned, mention them - Explain what `+` does earlier - Remove "might be added in the future" (it's a given that software might change in the future) Signed-off-by: Julia Evans <[email protected]>
1 parent c109793 commit 30a8f63

File tree

1 file changed

+82
-82
lines changed

1 file changed

+82
-82
lines changed

Documentation/git-push.adoc

Lines changed: 82 additions & 82 deletions
Original file line numberDiff line numberDiff line change
@@ -57,96 +57,96 @@ OPTIONS[[OPTIONS]]
5757

5858
<refspec>...::
5959
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.
8260
+
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
131128
(or using `--force` command line option). The only exception to this
132129
is that no amount of forcing will make the `refs/heads/*` namespace
133130
accept a non-commit object. Hooks and configuration can also override
134131
or amend these rules, see e.g. `receive.denyNonFastForwards` in
135132
linkgit:git-config[1] and `pre-receive` and `update` in
136133
linkgit:githooks[5].
137134
+
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.
150150

151151
--all::
152152
--branches::

0 commit comments

Comments
 (0)