summaryrefslogtreecommitdiff
path: root/Documentation/fetch-options.txt
AgeCommit message (Collapse)AuthorFilesLines
2015-03-13*config.txt: stick to camelCase naming conventionLibravatar Nguyễn Thái Ngọc Duy1-1/+1
This should improve readability. Compare "thislongname" and "thisLongName". The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-05fetch: allow explicit --refmap to override configurationLibravatar Junio C Hamano1-0/+8
Since the introduction of opportunisitic updates of remote-tracking branches, started at around f2690487 (fetch: opportunistically update tracking refs, 2013-05-11) with a few updates in v1.8.4 era, the remote.*.fetch configuration always kicks in even when a refspec to specify what to fetch is given on the command line, and there is no way to disable or override it per-invocation. Teach the command to pay attention to the --refmap=<lhs>:<rhs> command-line options that can be used to override the use of configured remote.*.fetch as the refmap. Signed-off-by: Junio C Hamano <gitster@pobox.com> ---
2014-01-17Merge branch 'nd/shallow-clone'Libravatar Junio C Hamano1-2/+12
Fetching from a shallow-cloned repository used to be forbidden, primarily because the codepaths involved were not carefully vetted and we did not bother supporting such usage. This attempts to allow object transfer out of a shallow-cloned repository in a controlled way (i.e. the receiver become a shallow repository with truncated history). * nd/shallow-clone: (31 commits) t5537: fix incorrect expectation in test case 10 shallow: remove unused code send-pack.c: mark a file-local function static git-clone.txt: remove shallow clone limitations prune: clean .git/shallow after pruning objects clone: use git protocol for cloning shallow repo locally send-pack: support pushing from a shallow clone via http receive-pack: support pushing to a shallow clone via http smart-http: support shallow fetch/clone remote-curl: pass ref SHA-1 to fetch-pack as well send-pack: support pushing to a shallow clone receive-pack: allow pushes that update .git/shallow connected.c: add new variant that runs with --shallow-file add GIT_SHALLOW_FILE to propagate --shallow-file to subprocesses receive/send-pack: support pushing from a shallow clone receive-pack: reorder some code in unpack() fetch: add --update-shallow to accept refs that update .git/shallow upload-pack: make sure deepening preserves shallow roots fetch: support fetching from a shallow repository clone: support remote shallow repository ...
2013-12-10fetch: add --update-shallow to accept refs that update .git/shallowLibravatar Nguyễn Thái Ngọc Duy1-0/+6
The same steps are done as in when --update-shallow is not given. The only difference is we now add all shallow commits in "ours" and "theirs" to .git/shallow (aka "step 8"). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-10upload-pack: make sure deepening preserves shallow rootsLibravatar Nguyễn Thái Ngọc Duy1-2/+6
When "fetch --depth=N" where N exceeds the longest chain of history in the source repo, usually we just send an "unshallow" line to the client so full history is obtained. When the source repo is shallow we need to make sure to "unshallow" the current shallow point _and_ "shallow" again when the commit reaches its shallow bottom in the source repo. This should fix both cases: large <N> and --unshallow. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30fetch-options.txt: simplify ifdef/ifndef/endif usageLibravatar Michael Haggerty1-4/+1
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30fetch --prune: prune only based on explicit refspecsLibravatar Michael Haggerty1-5/+14
The old behavior of "fetch --prune" was to prune whatever was being fetched. In particular, "fetch --prune --tags" caused tags not only to be fetched, but also to be pruned. This is inappropriate because there is only one tags namespace that is shared among the local repository and all remotes. Therefore, if the user defines a local tag and then runs "git fetch --prune --tags", then the local tag is deleted. Moreover, "--prune" and "--tags" can also be configured via fetch.prune / remote.<name>.prune and remote.<name>.tagopt, making it even less obvious that an invocation of "git fetch" could result in tag lossage. Since the command "git remote update" invokes "git fetch", it had the same problem. The command "git remote prune", on the other hand, disregarded the setting of remote.<name>.tagopt, and so its behavior was inconsistent with that of the other commands. So the old behavior made it too easy to lose tags. To fix this problem, change "fetch --prune" to prune references based only on refspecs specified explicitly by the user, either on the command line or via remote.<name>.fetch. Thus, tags are no longer made subject to pruning by the --tags option or the remote.<name>.tagopt setting. However, tags *are* still subject to pruning if they are fetched as part of a refspec, and that is good. For example: * On the command line, git fetch --prune 'refs/tags/*:refs/tags/*' causes tags, and only tags, to be fetched and pruned, and is therefore a simple way for the user to get the equivalent of the old behavior of "--prune --tag". * For a remote that was configured with the "--mirror" option, the configuration is set to include [remote "name"] fetch = +refs/*:refs/* , which causes tags to be subject to pruning along with all other references. This is the behavior that will typically be desired for a mirror. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-30fetch --tags: fetch tags *in addition to* other stuffLibravatar Michael Haggerty1-5/+3
Previously, fetch's "--tags" option was considered equivalent to specifying the refspec "refs/tags/*:refs/tags/*" on the command line; in particular, it caused the remote.<name>.refspec configuration to be ignored. But it is not very useful to fetch tags without also fetching other references, whereas it *is* quite useful to be able to fetch tags *in addition to* other references. So change the semantics of this option to do the latter. If a user wants to fetch *only* tags, then it is still possible to specifying an explicit refspec: git fetch <remote> 'refs/tags/*:refs/tags/*' Please note that the documentation prior to 1.8.0.3 was ambiguous about this aspect of "fetch --tags" behavior. Commit f0cb2f137c 2012-12-14 fetch --tags: clarify documentation made the documentation match the old behavior. This commit changes the documentation to match the new behavior. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-11Merge branch 'rr/maint-fetch-tag-doc-asterisks'Libravatar Junio C Hamano1-1/+1
* rr/maint-fetch-tag-doc-asterisks: fetch-options.txt: prevent a wildcard refspec from getting misformatted
2013-06-07fetch-options.txt: prevent a wildcard refspec from getting misformattedLibravatar Junio C Hamano1-1/+1
When explaining the "--tags" option as an equivalent to giving an explicit "refs/tags/*:refs/tags/*" refspec, the two asterisks were misinterpreted by AsciiDoc as a request to typeset the string segment between them in bold. We could fix it in two ways. We can replace them with {asterisk}s while keeping the string as body text, or we can mark it as a literal string with backquotes around it. Let's do the latter, as it is teaching the user an "exactly as typed" alternative. Noticed-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-11fetch: elaborate --depth actionLibravatar Nguyễn Thái Ngọc Duy1-1/+1
--depth is explained as deepen, but the way it's applied, it can shorten the history as well. Keen users may have noticed the implication by the phrase "the specified number of commits from the tip of each remote branch". Put "shorten" in the description to make it clearer. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-11fetch: add --unshallow for turning shallow repo into complete oneLibravatar Nguyễn Thái Ngọc Duy1-0/+4
The user can do --depth=2147483647 (*) for restoring complete repo now. But it's hard to remember. Any other numbers larger than the longest commit chain in the repository would also do, but some guessing may be involved. Make easy-to-remember --unshallow an alias for --depth=2147483647. Make upload-pack recognize this special number as infinite depth. The effect is essentially the same as before, except that upload-pack is more efficient because it does not have to traverse to the bottom anymore. The chance of a user actually wanting exactly 2147483647 commits depth, not infinite, on a repository with a history that long, is probably too small to consider. The client can learn to add or subtract one commit to avoid the special treatment when that actually happens. (*) This is the largest positive number a 32-bit signed integer can contain. JGit and older C Git store depth as "int" so both are OK with this number. Dulwich does not support shallow clone. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-13fetch --tags: clarify documentationLibravatar Junio C Hamano1-8/+5
Explain that --tags is just like another explicit refspec on the command line and as such overrides the default refspecs configured via the remote.$name.fetch variable. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-18Doc: shallow clone deepens _to_ new depthLibravatar Philip Oakley1-1/+2
Clarify that 'depth=' specifies the new depth from the remote's branch tip. It does not add the depth to the existing shallow clone. (details from pack-protocol.txt). Clarify that tags are not fetched. (details from shallow.txt) Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09fetch/pull: Don't recurse into a submodule when commits are already presentLibravatar Jens Lehmann1-1/+2
When looking for submodules where new commits have been recorded in the superproject ignore those cases where the submodules commits are already present locally. This can happen e.g. when the submodule has been rewound to an earlier state. Then there is no need to fetch the submodule again as the commit recorded in the newly fetched superproject commit has already been fetched earlier into the submodule. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09fetch/pull: Add the 'on-demand' value to the --recurse-submodules optionLibravatar Jens Lehmann1-3/+13
Until now the --recurse-submodules option could only be used to either fetch all populated submodules recursively or to disable recursion completely. As fetch and pull now by default just fetch those submodules for which new commits have been fetched in the superproject, a command line option to enforce that behavior is needed to be able to override configuration settings. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09fetch/pull: recurse into submodules when necessaryLibravatar Jens Lehmann1-0/+8
To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-07pull: Document the "--[no-]recurse-submodules" optionsLibravatar Jens Lehmann1-2/+0
In commits be254a0ea9 and 7dce19d374 the handling of the new fetch options "--[no-]recurse-submodules" had been added to git-pull.sh. But they were not documented as the pull options they now are, so let's fix that. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-16Merge branch 'jl/fetch-submodule-recursive'Libravatar Junio C Hamano1-0/+11
* jl/fetch-submodule-recursive: fetch_populated_submodules(): document dynamic allocation Submodules: Add the "fetchRecurseSubmodules" config option Add the 'fetch.recurseSubmodules' config setting fetch/pull: Add the --recurse-submodules option Conflicts: builtin/fetch.c
2010-11-24Merge branch 'mm/phrase-remote-tracking'Libravatar Junio C Hamano1-1/+1
* mm/phrase-remote-tracking: git-branch.txt: mention --set-upstream as a way to change upstream configuration user-manual: remote-tracking can be checked out, with detached HEAD user-manual.txt: explain better the remote(-tracking) branch terms Change incorrect "remote branch" to "remote tracking branch" in C code Change incorrect uses of "remote branch" meaning "remote-tracking" Change "tracking branch" to "remote-tracking branch" everyday.txt: change "tracking branch" to "remote-tracking branch" Change remote tracking to remote-tracking in non-trivial places Replace "remote tracking" with "remote-tracking" Better "Changed but not updated" message in git-status
2010-11-12Submodules: Add the "fetchRecurseSubmodules" config optionLibravatar Jens Lehmann1-1/+1
The new boolean "fetchRecurseSubmodules" config option controls the behavior for "git fetch" and "git pull". It specifies if these commands should recurse into submodules and fetch new commits there too and can be set separately for each submodule. In the .gitmodules file "submodule.<name>.fetchRecurseSubmodules" entries are read before looking for them in .git/config. Thus settings found in .git/config will override those from .gitmodules, thereby allowing the user to ignore settings given by the remote side while also letting upstream set reasonable defaults for those users who don't have special needs. This configuration can be overridden by the command line option "--[no-]recurse-submodules" of "git fetch" and "git pull". Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-12Add the 'fetch.recurseSubmodules' config settingLibravatar Jens Lehmann1-2/+3
This new boolean option can be used to override the default for "git fetch" and "git pull", which is to not recurse into populated submodules and fetch all new commits there too. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-12fetch/pull: Add the --recurse-submodules optionLibravatar Jens Lehmann1-0/+10
Until now you had to call "git submodule update" (without -N|--no-fetch option) or something like "git submodule foreach git fetch" to fetch new commits in populated submodules from their remote. This could lead to "(commits not present)" messages in the output of "git diff --submodule" (which is used by "git gui" and "gitk") after fetching or pulling new commits in the superproject and is an obstacle for implementing recursive checkout of submodules. Also "git submodule update" cannot fetch changes when disconnected, so it was very easy to forget to fetch the submodule changes before disconnecting only to discover later that they are needed. This patch adds the "--recurse-submodules" option to recursively fetch each populated submodule from the url configured in the .git/config of the submodule at the end of each "git fetch" or during "git pull" in the superproject. The submodule paths are taken from the index. The hidden option "--submodule-prefix" is added to "git fetch" to be able to print out the full paths of nested submodules. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03pull: Remove --tags option from manpageLibravatar Jens Lehmann1-0/+2
"Fetch all tags and merge them" does not make any sense as a request at the logical level, even though it might be more convenient to type. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03Replace "remote tracking" with "remote-tracking"Libravatar Matthieu Moy1-1/+1
"remote-tracking" branch makes it explicit that the branch is "tracking a remote", as opposed to "remote, and tracking something". See discussion in e.g. http://mid.gmane.org/8835ADF9-45E5-4A26-9F7F-A72ECC065BB2@gmail.com for more details. This patch is a straightforward application of perl -pi -e 's/remote tracking branch/remote-tracking branch/' except in the RelNotes directory. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-14fetch: allow command line --tags to override configLibravatar Daniel Johnson1-2/+6
Originally, if remote.<name>.tagopt was set, the --tags and option would have no effect when given to git fetch. So if tagopt="--no-tags" git fetch --tags would not actually fetch tags. This patch changes this behavior to only follow what is written in the config if there is no option passed by the command line. Signed-off-by: Daniel Johnson <ComputerDruid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-13git fetch documentation: describe short '-p' synonym to '--prune' optionLibravatar Oren Held1-0/+1
It's already implemented, just undocumented. Signed-off-by: Oren Held <orenhe@il.ibm.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24fetch and pull: learn --progressLibravatar Tay Ray Chuan1-1/+8
Note that in the documentation for git-pull, documentation for the --progress option is displayed under the "Options related to fetching" subtitle via fetch-options.txt. Also, update the documentation of the -q/--quiet option for git-pull to mention its effect on progress reporting during fetching. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-5/+5
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-10builtin-fetch: add --dry-run optionLibravatar Jay Soffian1-0/+5
Teach fetch --dry-run as users of "git remote prune" switching to "git fetch --prune" may expect it. Unfortunately OPT__DRY_RUN() cannot be used as fetch already uses "-n" for something else. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10builtin-fetch: add --prune optionLibravatar Jay Soffian1-0/+4
Teach fetch to cull stale remote tracking branches after fetching via --prune. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Teach the --multiple option to 'git fetch'Libravatar Björn Gustavsson1-0/+6
Add the --multiple option to specify that all arguments are either groups or remotes. The primary reason for adding this option is to allow us to re-implement 'git remote update' using fetch. It would have been nice if this option was not needed, but since the colon in a refspec is optional, it is in general not possible to know whether a single, colon-less argument is a remote or a refspec. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-10Teach the --all option to 'git fetch'Libravatar Björn Gustavsson1-0/+3
'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-21Documentation/fetch-options.txt: order options alphabeticallyLibravatar Jari Aalto1-24/+24
git-fetch.{1,html} will be helped with this patch Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-07git-pull: do not mention --quiet and --verbose twiceLibravatar Emmanuel Trillaud1-0/+2
git-pull.txt includes fetch-options.txt and merge-options.txt, both of which document the --quiet and --verbose. Supress the ones from fetch-options.txt. Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-12Change mentions of "git programs" to "git commands"Libravatar Ori Avtalion1-1/+1
Most of the docs and printouts refer to "commands" when discussing what the end users call via the "git" top-level program. We should refer them as "git programs" when we discuss the fact that the commands are implemented as separate programs, but in other contexts, it is better to use the term "git commands" consistently. Signed-off-by: Ori Avtalion <ori@avtalion.name> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> 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-06-08Docs: Use "-l::\n--long\n" format in OPTIONS sectionsLibravatar Stephan Beyer1-11/+19
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>
2008-01-25git pull manpage: don't include -n from fetch-options.txtLibravatar Miklos Vajna1-4/+8
The -n option stands for --no-summary in git pull [jes: reworded the description to avoid mentioning 'git-fetch'; also exclude '-n' conditional on git-pull -- ugly because of the missing "else" statement in asciidoc] Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-06Documentation: rename gitlink macro to linkgitLibravatar Dan McGee1-1/+1
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>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+0
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-04-26Document additional options for git-fetchLibravatar Andrew Ruder1-5/+12
Document --quiet/-q and --verbose/-v Add -n as an alternate for --no-tags Fix some whitespace issues Signed-off-by: Andrew Ruder <andy@aeruder.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-01Update clone/fetch documentation with --depth (shallow clone) optionLibravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-01Strongly discourage --update-head-ok in fetch-options documentation.Libravatar Junio C Hamano1-2/+4
"Use it with care" is a wrong wording to say "this is purely internal and you are supposed to know what you are doing if you use this". Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-26git-fetch --upload-pack: disambiguate.Libravatar Junio C Hamano1-2/+1
Johannes noticed the recent addition of this new flag inadvertently took over existing --update-head-ok (-u). Require longer abbreviation to this new option which would be needed in a rare setup. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-24git-fetch: pass --upload-pack to fetch-packLibravatar Michal Ostrowski1-0/+7
Without this, there is no way to specify a remote executable when invoking git-pull/git-fetch as there is for git-clone. [jc: I have a mild suspicion that this is a broken environment (aka sysadmin disservice). It may be legal to configure your sshd to spawn named program without involving shell at all, and if your sysadmin does so and you have your git programs under your home directory, you would need something like this, but then I suspect you would need such workaround everywhere, not just git. But we have these options we can use to work around the issue, so there is no strong reason not to reject this patch, either. ] Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-10Add --keep option to keep downloaded packs to git-fetch.Libravatar Tom Prince1-0/+3
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-07git-fetch: auto-following tags.Libravatar Junio C Hamano1-5/+13
I added things to ls-remote so that Cogito can auto-follow tags easily and correctly a while ago, but git-fetch did not use the facility. Recently added git-describe command relies on repository keeping up-to-date set of tags, which made it much more attractive to automatically follow tags, so we do that as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-01Documentation: describe '-f' option to git-fetch.Libravatar Junio C Hamano1-0/+5
The option description header was there without body text, confusingly getting rendered as if the description for --tags applied to the option. Noticed by Carl Baldwin. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Update pull/fetch --tags documentationLibravatar Luck, Tony1-1/+3
When fetching/pulling from a remote repository the "--tags" option can be used to pull tags too. Document that it will limit the pull to only commits reachable from the tags. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Junio C Hamano <junkio@cox.net>