summaryrefslogtreecommitdiff
path: root/Documentation/urls.txt
AgeCommit message (Collapse)Author
2008-02-25Add support for url aliases in config filesDaniel Barkalow
This allows users with different preferences for access methods to the same remote repositories to rewrite each other's URLs by pattern matching across a large set of similiarly set up repositories to each get the desired access. For example, if you don't have a kernel.org account, you might want settings like: [url "git://git.kernel.org/pub/"] insteadOf = master.kernel.org:/pub Then, if you give git a URL like: master.kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git it will act like you gave it: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git and you can cut-and-paste pull requests in email without fixing them by hand, for example. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-07Documentation: rename gitlink macro to linkgitDan McGee
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-11-17Documentation: fix git-clone manpage not to refer to itselfSergei Organov
Signed-off-by: Sergei Organov <osv@javad.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-01URL: allow port specification in ssh:// URLsLuben Tuikov
Allow port specification in ssh:// URLs in the usual notation: ssh://[user@]host.domain[:<port>]/<path> This allows git to be used over ssh-tunneling networks. Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-02git-clone: aggressively optimize local clone behaviour.Junio C Hamano
This changes the behaviour of cloning from a repository on the local machine, by defaulting to "-l" (use hardlinks to share files under .git/objects) and making "-l" a no-op. A new option, --no-hardlinks, is also added to cause file-level copy of files under .git/objects while still avoiding the normal "pack to pipe, then receive and index pack" network transfer overhead. The old behaviour of local cloning without -l nor -s is availble by specifying the source repository with the newly introduced file:///path/to/repo.git/ syntax (i.e. "same as network" cloning). * With --no-hardlinks (i.e. have all .git/objects/ copied via cpio) would not catch the source repository corruption, and also risks corrupted recipient repository if an alpha-particle hits memory cell while indexing and resolving deltas. As long as the recipient is created uncorrupted, you have a good back-up. * same-as-network is expensive, but it would catch the breakage of the source repository. It still risks corrupted recipient repository due to hardware failure. As long as the recipient is created uncorrupted, you have a good back-up. * The new default on the same filesystem, as long as the source repository is healthy, it is very likely that the recipient would be, too. Also it is very cheap. You do not get any back-up benefit, though. None of the method is resilient against the source repository corruption, so let's discount that from the comparison. Then the difference with and without --no-hardlinks matters primarily if you value the back-up benefit or not. If you want to use the cloned repository as a back-up, then it is cheaper to do a clone with --no-hardlinks and two git-fsck (source before clone, recipient after clone) than same-as-network clone, especially as you are likely to do a git-fsck on the recipient if you are so paranoid anyway. Which leads me to believe that being able to use file:/// is probably a good idea, if only for testability, but probably of little practical value. We default to hardlinked clone for everyday use, and paranoids can use --no-hardlinks as a way to make a back-up. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-06Add urls.txt to git-clone man pageAndrew Ruder
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>
2007-01-01Fix formatting for urls section of fetch, pull, and push manpagesTheodore Tso
Updated to make the nroff'ed man pages look nicer. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31Fix formatting for urls section of fetch, pull, and push manpagesTheodore Ts'o
The line: [remote "<remote>"] was getting swallowed up by asciidoc, causing a critical line in the explanation for how to store the .git/remotes information in .git/config to go missing from the git-fetch, git-pull, and git-push manpages. Put all of the examples into delimited blocks to fix this problem and to make them look nicer. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-23Documentation for the [remote] configSanti Béjar
Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-14Documentation/urls.txt: Use substitution to escape square bracketsJonas Fonseca
This changes "[user@]" to use {startsb} and {endsb} to insert [ and ], similar to how {caret} is used in git-rev-parse.txt. [jc: Removed a well-intentioned comment that broke the final formatting from the original patch. While we are at it, updated the paragraph that claims to be equivalent to the section that was updated earlier without making matching changes.] Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-14documentation (urls.txt) typofixAlp Toker
2006-07-14Documentation: Fix ssh://[user@]host.xz URLJunio C Hamano
Earlier commit c3f17061 broke asciidoc markup. Noticed by Alp Toker with a fix, but fixed up in a way with smaller formatting impact. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-11Mention the [user@] part in documentation of ssh:// urls.Yakov Lerner
Signed-off-by: Yakov Lerner <iler.ml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-09Fix some doubled word typosAlp Toker
Signed-off-by: Alp Toker <alp@atoker.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-07Docs: move git url and remotes text to separate sectionsJ. Bruce Fields
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-07Docs: split up pull-fetch-param.txtJ. Bruce Fields
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>