While b259f09 made git-push output a better error message for 'git-push
--all --tags', this commit fixes the synopsis in the documentation.
Inconsistency spotted and fix suggested by Jari Aalto through
http://bugs.debian.org/502567
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This tries to make the description of ref matching in git push easier
to read. Beauty is in the eye of the beholder, though.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Include examples of using HEAD. The order of examples
introduces new concepts one by one. This pushes the
example of deleting a ref to the end of the list.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The refspec format description was a mix of regexp and BNF, making it
very difficult to read. The format was also wrong: it did not show
that each part of a refspec is optional in different situations.
Rather than having a confusing grammar, just present the format in
informal prose.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The <ref> parameter has not been introduced, so rewrite to
avoid it.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "matching refs" semantics works only on matching branches these days.
Instead of using "heads" which traditionally has been used more or less
interchangeably with "refs", say "branch" explicitly here.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The comment in parentheses is wrong, as one has to leave out both the
colon and <dst>. This situation is covered by the section a few lines
down:
A parameter <ref> without a colon pushes the <ref> from the source
repository to the destination repository under the same name.
So, just remove the parentheses.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is copied from pull-fetch-param.txt and helps the reader
to not get stuck in the URL section.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --repo option was described in a way that the reader would have to
assume that it is the same as the <repository> parameter. But it actually
servers a purpose, which is now written down.
Furthermore, the --mirror option was missing from the synopsis.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I see quite a few pages on k.org site, e.g.
http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html
(scroll down to find "After this test merge")
are misformatted to lose teletype text '+' that is followed by a comma,
and turns the following paragraph all typeset in teletype.
This patch seems to fix the issue at the site (meaning, with the
particular vintage of asciidoc and docbook toolchain), without breaking
things with the version I have at my primary development machine, but
wider testing is very much appreciated.
After this patch,
git grep '`+`,' -- Documentation
should report noting.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The names of git commands are not meant to be entered at the
commandline; they are just names. So we render them in italics,
as is usual for command names in manpages.
Using
doit () {
perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }'
}
for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \
merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt
do
doit <"$i" >"$i+" && mv "$i+" "$i"
done
git diff
.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Following what appears to be the predominant style, format
names of commands and commandlines both as `teletype text`.
While we're at it, add articles ("a" and "the") in some
places, italicize the name of the command in the manual page
synopsis line, and add a comma or two where it seems appropriate.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the git-* commands are not installed in $(bindir), using
"git-command <parameters>" in examples in the documentation is
not a good idea. On the other hand, it is nice to be able to
refer to each command using one hyphenated word. (There is no
escaping it, anyway: man page names cannot have spaces in them.)
This patch retains the dash in naming an operation, command,
program, process, or action. Complete command lines that can
be entered at a shell (i.e., without options omitted) are
made to use the dashless form.
The changes consist only of replacing some spaces with hyphens
and vice versa. After a "s/ /-/g", the unpatched and patched
versions are identical.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option behaves more like:
git push $url +refs/*:refs/*
than it does like:
git push $url +refs/heads/*:refs/heads/* +refs/tags/*:refs/tags/*
so we should document it to be more clear about that.
Suggested-by: Marek Zawirski <marek.zawirski@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The OPTIONS section of a documentation file contains a list
of the options a git command accepts.
Currently there are several variants to describe the case that
different options (almost) do the same in the OPTIONS section.
Some are:
-f, --foo::
-f|--foo::
-f | --foo::
But AsciiDoc has the special form:
-f::
--foo::
This patch applies this form to the documentation of the whole git suite,
and removes useless em-dash prevention, so \--foo becomes --foo.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As the "git" man page describes the "git" command at the end-user
level, it seems better to move it to man section 1.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch provides a way to specify "push matching heads" using a
special refspec ":". This is useful because it allows "push = +:"
as a way to specify that matching refs will be pushed but, in addition,
forced updates will be allowed, which was not possible before.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These paragraphs are a little confusing. Also, make it clearer when
you have to specify the full name for <dst>
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds a remote.*.mirror configuration option that,
when set, automatically puts git-push in --mirror mode for that
remote.
Furthermore, the option is set automatically by `git remote
add --mirror'.
The code in remote.c to parse remote.*.skipdefaultupdate
had a subtle problem: a comment in the code indicated that
special care was needed for boolean options, but this care was
not used in parsing the option. Since I was touching related
code, I did this fix too.
[jc: and I further fixed up the "ignore boolean" code.]
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The output was meant to be a balance of self-explanatory and
terse. In case we have erred too far on the terse side, it
doesn't hurt to explain in more detail what each line means.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous text was correct, but it was easy to miss the
fact that we are talking about "matching" refs. That is, the
text can be parsed as "we push the union of the sets
of remote and local heads" and not "we push the intersection
of the sets of remote and local heads". (The former actually
doesn't make sense if you think about it, since we don't
even _have_ some of those heads). A careful reading would
reveal the correct meaning, but it makes sense to be as
explicit as possible in documentation.
We also explicitly use and introduce the term "matching";
this is a term discussed on the list, and it seems useful
to for users to be able to refer to this behavior by name.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock
Asciidoc configuration:
@@ -149,7 +153,10 @@
# Inline macros.
# Backslash prefix required for escape processing.
# (?s) re flag for line spanning.
-(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
+# Explicit so they can be nested.
+(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
# Anchor: [[[id]]]. Bibliographic anchor.
(?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3
# Anchor: [[id,xreflabel]]
This default regex now matches explicit values, and unfortunately in this
case gitlink was being matched by just 'link', causing the wrong inline
macro template to be applied. By renaming the macro, we can avoid being
matched by the wrong regex.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add some basic documentation on the --mirror mode for git-push.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default behaviour of git-push is potentially confusing
for new users, since it will push changes that are not on
the current branch. Publishing patches that were still
cooking on a development branch is hard to undo.
It would also be nice to be able to verify the expansion
of refspecs if you've edited them, so that you know
what branches matched on the server.
Adding a --dry-run flag allows the user to experiment
safely and learn how to use git-push properly. Originally
suggested by Steffen Prohaska.
Signed-off-by: Brian Ewins <brian.ewins@gmail.com>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commit 098e711e caused git-push to match only branches when
considering which refs to push. This patch updates the
documentation accordingly and adds a test for this behavior.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many users get confused when `git push origin master:foo` works
when foo already exists on the remote repository but are confused
when foo doesn't exist as a branch and this form does not create
the branch foo.
This new example highlights the trick of including refs/heads/
in front of the desired branch name to create a branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In git-push it is the remote repository and not the
local repository which is fast forwarded. The description
of the -f option in the git-push manpage gets it the other
way round.
Signed-off-by: Jyotirmoy Bhattacharya <jyotirmoy@jyotirmoy.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since git-clone is one of the many commands taking
URLs to remote repositories as an argument, it should include
the URL-types list from urls.txt.
Split up urls.txt into urls.txt and urls-remotes.txt. The latter
should be used by anything besides git-clone where a discussion of
using .git/config and .git/remotes/ to name URLs just doesn't make
as much sense.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For now it's just to get a more descriptive name. Later we might update the
push protocol to run more than one program on the other end. Moreover this
matches better the corresponding config option remote.<name>. receivepack.
--exec continues to work
Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
add all supported options to Documentation/git-....txt and the usage strings.
Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The text is just copied from git-send-pack.txt.
Signed-off-by: Uwe Kleine-K,Av(Bnig <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This was already documented in the options section of the manpage. This
patch implements it, adds it to the usage message, and mentions it at the
top of the manpage.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It turns out that the git-push documentation didn't describe what it
would do when not given a refspec, (not on the command line, nor in a
remotes file). This is fairly important for the user who is trying to
understand operations such as:
git clone git://something/some/where
# hack, hack, hack
git push origin
I tracked the mystery behavior down to git-send-pack and lifted the
relevant portion of its documentation up to git-push, (namely that all
refs existing both locally and remotely are updated).
Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The sections on git urls and remotes files in the git-fetch,
git-pull, and git-push manpages seem long enough to be worth a
manpage section of their own.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The push and pull man pages include a bunch of shared text from
pull-fetch-param.txt. This simplifies maintenance somewhat, but
there's actually quite a bit of text that applies only to one or the
other.
So, separate out the push- and pull/fetch-specific text into
pull-fetch-param.txt and git-push.txt, then include the largest chunk
of common stuff (the description of protocols and url's) from
urls.txt. That cuts some irrelevant stuff from the man pages without
making us duplicate too much.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Chris Johnsen