summaryrefslogtreecommitdiff
path: root/Documentation/pull-fetch-param.txt
AgeCommit message (Collapse)AuthorFilesLines
2020-04-05pull doc: refer to a specific section in 'fetch' docLibravatar Philippe Blain1-1/+2
The documentation for the `<refspec>` parameter in the `git fetch` documentation refers to the section "CONFIGURED REMOTE-TRACKING BRANCHES" in this same documentation page. In the `git pull` documentation, let's also refer specifically to this section instead of just linking to the `git fetch` documentation. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-20fetch doc: correct grammar in --force docsLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Correct a grammar error (saying "the receiving" made no sense) in the recently landed documentation added in my 0bc8d71b99 ("fetch: stop clobbering existing tags without --force", 2018-08-31) by rephrasing the sentence. Also correct 'fetching work the same way' by s/work/&s/; Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31fetch: stop clobbering existing tags without --forceLibravatar Ævar Arnfjörð Bjarmason1-4/+11
Change "fetch" to treat "+" in refspecs (aka --force) to mean we should clobber a local tag of the same name. This changes the long-standing behavior of "fetch" added in 853a3697dc ("[PATCH] Multi-head fetch.", 2005-08-20). Before this change, all tag fetches effectively had --force enabled. See the git-fetch-script code in fast_forward_local() with the comment: > Tags need not be pointing at commits so there is no way to > guarantee "fast-forward" anyway. That commit and the rest of the history of "fetch" shows that the "+" (--force) part of refpecs was only conceived for branch updates, while tags have accepted any changes from upstream unconditionally and clobbered the local tag object. Changing this behavior has been discussed as early as 2011[1]. The current behavior doesn't make sense to me, it easily results in local tags accidentally being clobbered. We could namespace our tags per-remote and not locally populate refs/tags/*, but as with my 97716d217c ("fetch: add a --prune-tags option and fetch.pruneTags config", 2018-02-09) it's easier to work around the current implementation than to fix the root cause. So this change implements suggestion #1 from Jeff's 2011 E-Mail[1], "fetch" now only clobbers the tag if either "+" is provided as part of the refspec, or if "--force" is provided on the command-line. This also makes it nicely symmetrical with how "tag" itself works when creating tags. I.e. we refuse to clobber any existing tags unless "--force" is supplied. Now we can refuse all such clobbering, whether it would happen by clobbering a local tag with "tag", or by fetching it from the remote with "fetch". Ref updates outside refs/{tags,heads/* are still still not symmetrical with how "git push" works, as discussed in the recently changed pull-fetch-param.txt documentation. This change brings the two divergent behaviors more into line with one another. I don't think there's any reason "fetch" couldn't fully converge with the behavior used by "push", but that's a topic for another change. One of the tests added in 31b808a032 ("clone --single: limit the fetch refspec to fetched branch", 2012-09-20) is being changed to use --force where a clone would clobber a tag. This changes nothing about the existing behavior of the test. 1. https://public-inbox.org/git/20111123221658.GA22313@sigill.intra.peff.net/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31fetch: document local ref updates with/without --forceLibravatar Ævar Arnfjörð Bjarmason1-5/+27
Refer to the new git-push(1) documentation about when ref updates are and aren't allowed with and without --force, noting how "git-fetch" differs from the behavior of "git-push". Perhaps it would be better to split this all out into a new gitrefspecs(7) man page, or present this information using tables. In lieu of that, this is accurate, and fixes a big omission in the existing refspec docs. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13pull doc: fix a long-standing grammar errorLibravatar Ævar Arnfjörð Bjarmason1-1/+1
It should be "is not an empty string" not "is not empty string". This fixes wording originally introduced in ab9b31386b ("Documentation: multi-head fetch.", 2005-08-24). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-18fetch doc: src side of refspec could be full SHA-1Libravatar Junio C Hamano1-2/+4
Since a9d34933 ("Merge branch 'fm/fetch-raw-sha1'", 2015-06-01) we allow to fetch by an object name when the other side accepts such a request, but we never updated the documentation to match. Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-12docs: Explain the purpose of fetch's and pull's <refspec> parameter.Libravatar Marc Branchaud1-4/+14
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-04fetch doc: remove "short-cut" sectionLibravatar Junio C Hamano1-13/+3
It is misleading to mention that <ref> that does not store is to fetch the ref into FETCH_HEAD, because a refspec that does store is also to fetch the LHS into FETCH_HEAD. It is doubly misleading to list it as part of "short-cut". <ref> stands for a refspec that has it on the LHS with a colon and an empty RHS, and that definition should be given at the beginning of the entry where the format is defined. Tentatively remove this misleading description, which leaves the `tag <tag>` as the only true short-hand, so move it at the beginning of the entry. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-04fetch doc: update refspec format descriptionLibravatar Junio C Hamano1-0/+1
The text made it sound as if the leading plus is the only thing that is optional, and forgot that <lhs> is the same as <lhs>:, i.e. fetch it and do not store anywhere. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-04fetch doc: on pulling multiple refspecsLibravatar Junio C Hamano1-7/+12
Replace desription of old-style "Pull:" lines in remotes/ configuration with modern remote.*.fetch variables. As this note applies only to "git pull", enable it only in git-pull manual page. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-02fetch doc: remove notes on outdated "mixed layout"Libravatar Junio C Hamano1-13/+0
In old days before Git 1.5, it was customery for "git fetch" to use the same local branch namespace to keep track of the remote-tracking branches, and it was necessary to tell users not to check them out and commit on them. Since everybody uses the separate remote layout these days, there is no need to warn against the practice to check out the right-hand side of <refspec> and build on it---the RHS is typically not even a local branch. Incidentally, this also kills one mention of "Pull:" line of $GIT_DIR/remotes/* configuration, which is a lot less familiar to new people than the more modern remote.*.fetch configuration variable. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-02fetch doc: update note on '+' in front of the refspecLibravatar Junio C Hamano1-9/+9
While it is not *wrong* per-se to say that pulling a rewound/rebased branch will lead to an unnecessary merge conflict, that is not what the leading "+" sign to allow non-fast-forward update of remote-tracking branch is at all. Helped-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-12fetch: opportunistically update tracking refsLibravatar Jeff King1-1/+1
When we run a regular "git fetch" without arguments, we update the tracking refs according to the configured refspec. However, when we run "git fetch origin master" (or "git pull origin master"), we do not look at the configured refspecs at all, and just update FETCH_HEAD. We miss an opportunity to update "refs/remotes/origin/master" (or whatever the user has configured). Some users find this confusing, because they would want to do further comparisons against the old state of the remote master, like: $ git pull origin master $ git log HEAD...origin/master In the currnet code, they are comparing against whatever commit happened to be in origin/master from the last time they did a complete "git fetch". This patch will update a ref from the RHS of a configured refspec whenever we happen to be fetching its LHS. That makes the case above work. The downside is that any users who really care about whether and when their tracking branches are updated may be surprised. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-12fetch/pull doc: untangle meaning of bare <ref>Libravatar Thomas Rast1-3/+8
The documentation erroneously used the same wording for both fetch and pull, stating that something will be merged even in git-fetch(1). In addition, saying that "<ref> is equivalent to <ref>:" doesn't really help anyone who still needs to read manpages. Clarify what is actually going on. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-1/+1
In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-4/+4
The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.
2009-11-23Merge branch 'bg/fetch-multi'Libravatar Junio C Hamano1-0/+7
* bg/fetch-multi: Re-implement 'git remote update' using 'git fetch' builtin-fetch: add --dry-run option builtin-fetch: add --prune option teach warn_dangling_symref to take a FILE argument remote: refactor some logic into get_stale_heads() Add missing test for 'git remote update --prune' Add the configuration option skipFetchAll Teach the --multiple option to 'git fetch' Teach the --all option to 'git fetch'
2009-11-10Teach the --all option to 'git fetch'Libravatar Björn Gustavsson1-0/+7
'git remote' is meant for managing remotes and 'git fetch' is meant for actually fetching data from remote repositories. Therefore, it is not logical that you must use 'git remote update' to fetch from more than one repository at once. Add the --all option to 'git fetch', to tell it to attempt to fetch from all remotes. Also, if --all is not given, the <repository> argument is allowed to be the name of a group, to allow fetching from all repositories in the group. Other options except -v and -q are silently ignored. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-24Use 'fast-forward' all over the placeLibravatar Felipe Contreras1-2/+2
It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-25Documentation: simplify refspec format descriptionLibravatar Junio C Hamano1-5/+4
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>
2008-08-09Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: asciidoc markup fixes Fail properly when cloning from invalid HTTP URL Conflicts: Documentation/git-push.txt
2008-08-07asciidoc markup fixesLibravatar Junio C Hamano1-1/+1
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>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-4/+4
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>
2008-05-31Clarify description of <repository> argument to pull/fetch for naming remotes.Libravatar John J. Franey1-1/+3
Alter the description of <repository> in OPTIONS section to explicitly state that a 'remote name' is accepted. Rewrite REMOTES section to more directly identify the different kinds of remote-name permitted. Signed-off-by: John J. Franey <jjfraney@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+1
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>
2007-01-01Documentation: remove master:origin example from pull-fetch-param.txtLibravatar J. Bruce Fields1-4/+0
This is no longer a useful example. Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06Docs: move git url and remotes text to separate sectionsLibravatar J. Bruce Fields1-2/+1
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>
2006-02-06Docs: split up pull-fetch-param.txtLibravatar J. Bruce Fields1-80/+6
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>
2006-01-12Documentation: clarify fetch parameter descriptions.Libravatar J. Bruce Fields1-3/+3
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-29Fix typos and minor format issues.Libravatar jdl@freescale.com1-7/+7
Signed-off-by: Jon Loeliger <jdl@freescale.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21git-daemon support for user-relative paths.Libravatar Andreas Ericsson1-3/+4
Dropped a fair amount of reundant code in favour of the library code in path.c Added option --strict-paths with documentation, with backwards compatibility for whitelist entries with symlinks. Everything that worked earlier still works insofar as I have remembered testing it. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Documentation update for user-relative paths.Libravatar Andreas Ericsson1-5/+24
Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-11Documentation: "host:path/to/repo" is git native over ssh.Libravatar Junio C Hamano1-1/+1
You could also spell it ssh://host:/path/to/repo (or git+ssh, ssh+git), but without method:// is shorter to type, so mention only that one in the short and sweet list. Noticed by Pasky. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-06Documentation: pull/clone ref mapping clarification.Libravatar Junio C Hamano1-8/+13
Josef Weidendorfer points out that git-clone documentation does not mention the initial copying of remote branch heads into corresponding local branches. Also clarify the purpose of the ref mappings description in the "remotes" file and recommended workflow. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-05Documentation: git-fetch/pull updates.Libravatar Junio C Hamano1-3/+19
We do not accept multiple <refspecs> on one Pull:/Push: line right now (we could lift this tentative workaround for the broken refnames), but we have always accepted multiple such lines, so use that form in the examples and discussion. Also explicitly mention that Octopus is made only with an explicit command line request and never from Pull: lines. Add a couple of cross references. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-04Added a few examples to git-pull man page.Libravatar Jon Loeliger1-23/+49
Clarified and added notes for pull/push refspecs. Converted to back-ticks for literal text examples. [jc: Also fixed git-pull description that still talked about its calling git-resolve or git-octopus (we do not anymore; instead we just call git-merge). BTW, I am reasonably impressed by how well "git-am -3" applied this patch, which had some conflicts because I've updated the documentation somewhat.] Signed-off-by: Jon Loeliger <jdl@freescale.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19git-fetch/push/pull: documentation.Libravatar Junio C Hamano1-10/+0
The documentation was lazily sharing the argument description across these commands. Lazy may be a way of life, but that does not justify confusing others ;-). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-10Convert usage of GIT and Git into gitLibravatar Christian Meder1-1/+1
Convert usage of GIT and Git into git. Signed-off-by: Christian Meder <chris@absolutegiganten.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-03[PATCH] Random documentation fixesLibravatar Jonas Fonseca1-72/+66
The fixes focuses on improving the HTML output. Most noteworthy: - Fix the Makefile to also make various *.html files depend on included files. - Consistently use 'NOTE: ...' instead of '[ ... ]' for additional info. - Fix ending '::' for description lists in OPTION section etc. - Fix paragraphs in description lists ending up as preformated text. - Always use listingblocks (preformatted text wrapped in lines with -----) for examples that span empty lines, so they are put in only one HTML block. - Use '1.' instead of '(1)' for numbered lists. - Fix linking to other GIT docs. - git-rev-list.txt: put option descriptions in an OPTION section. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-15[PATCH] Document git-fetch optionsLibravatar Sergey Vlasov1-0/+11
Add documentation for git-fetch options Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24Fix markup minimally to get man pages built.Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24Documentation: multi-head fetch.Libravatar Junio C Hamano1-17/+63
Add documentation related to multi-head work, including $GIT_DIR/remotes/ changes. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-16[PATCH] Documentation: describe short-hand used in fetch/pull.Libravatar Junio C Hamano1-0/+36
Describe short-hand for remote repository used in fetch/pull. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>