summaryrefslogtreecommitdiff
path: root/Documentation/git-clone.txt
AgeCommit message (Collapse)AuthorFilesLines
2009-11-30Documentation: Document --branch option in git clone synopsisLibravatar David Soria Parra1-1/+1
Document the --branch option as [-b <name>] in git clones synopsis. Signed-off-by: David Soria Parra <dsp@php.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-21git-clone.txt: Fix grammar and formattingLibravatar Björn Gustavsson1-13/+13
Add the missing definite article ("the") in several places. Change "note to..." to "note for...", since "note to" means that that the note is addressed to someone (source: Google search). Change "progressbar" to "progress bar" (source: Wikipedia). Format git commands, options, and file names consistently using back quotes (i.e. a fixed font in the resulting HTML document). Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-09Documentation: clone: clarify discussion of initial branchLibravatar Jonathan Nieder1-2/+3
When saying the initial branch is equal to the currently active remote branch, it is probably intended that the branch heads point to the same commit. Maybe it would be more useful to a new user to emphasize that the tree contents and history are the same. More important, probably, is that this new branch is set up so that "git pull" merges changes from the corresponding remote branch. The next paragraph addresses that directly. What the reader needs to know to begin with is that (1) the initial branch is your own; if you do not pull, it won't get updated, and that (2) the initial branch starts out at the same commit as the upstream. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13git-clone doc: typofixLibravatar Johannes Gilger1-1/+1
Signed-off-by: Johannes Gilger <heipei@hackvalue.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-07Merge branch 'jk/clone-b'Libravatar Junio C Hamano1-0/+7
* jk/clone-b: clone: add --branch option to select a different HEAD
2009-09-03Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: git-clone: add missing comma in --reference documentation
2009-09-03Merge branch 'maint-1.6.3' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.6.3: git-clone: add missing comma in --reference documentation git-cvsserver: no longer use deprecated 'git-subcommand' commands clone: disconnect transport after fetching
2009-09-03Merge branch 'maint-1.6.2' into maint-1.6.3Libravatar Junio C Hamano1-1/+1
* maint-1.6.2: git-clone: add missing comma in --reference documentation clone: disconnect transport after fetching
2009-09-03git-clone: add missing comma in --reference documentationLibravatar Miklos Vajna1-1/+1
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-27Merge branch 'jh/submodule-foreach'Libravatar Junio C Hamano1-1/+9
* jh/submodule-foreach: git clone: Add --recursive to automatically checkout (nested) submodules t7407: Use 'rev-parse --short' rather than bash's substring expansion notation git submodule status: Add --recursive to recurse into nested submodules git submodule update: Introduce --recursive to update nested submodules git submodule foreach: Add --recursive to recurse into nested submodules git submodule foreach: test access to submodule name as '$name' Add selftest for 'git submodule foreach' git submodule: Cleanup usage string and add option parsing to cmd_foreach() git submodule foreach: Provide access to submodule name, as '$name' Conflicts: Documentation/git-submodule.txt git-submodule.sh
2009-08-26clone: add --branch option to select a different HEADLibravatar Jeff King1-0/+7
We currently point the HEAD of a newly cloned repo to the same ref as the parent repo's HEAD. While a user can then "git checkout -b foo origin/foo" whichever branch they choose, it is more convenient and more efficient to tell clone which branch you want in the first place. Based on a patch by Kirill A. Korinskiy. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-20git clone: Add --recursive to automatically checkout (nested) submodulesLibravatar Johan Herland1-1/+9
Many projects using submodules expect all submodules to be checked out in order to build/work correctly. A common command sequence for developers on such projects is: git clone url/to/project cd project git submodule update --init (--recursive) This patch introduces the --recursive option to git-clone. The new option causes git-clone to recursively clone and checkout all submodules of the cloned project. Hence, the above command sequence can be reduced to: git clone --recursive url/to/project --recursive is ignored if no checkout is done by the git-clone. The patch also includes documentation and a selftest. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-17docs: describe impact of repack on "clone -s"Libravatar Jeff King1-2/+10
The effects of repacking on a repository with alternates are a bit subtle. The two main things users will want are: 1. Not to waste disk space by accidentally copying objects which could be shared. 2. Copying all objects explicitly to break the dependency on the source repo. This patch describes both under the "clone -s" documentation. It makes sense to put it there rather than in git-repack.txt for both cases. For (1), we are warning the user who is using "clone -s" about what _not_ to do, so we need to get their attention when reading about "clone -s". For (2), we are telling them how git-repack can be used to accomplish a task, but until they know that git-repack is the right tool, they have no reason to look at the repack documentation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-09Documentation: cloning to empty directory is allowedLibravatar Alexander Potashev1-1/+1
Cloning into an existing empty directory is now allowed: commit 55892d23981917aefdb387ad7d0429f90cbd446a ("Allow cloning to an existing empty directory") Signed-off-by: Alexander Potashev <aspotashev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-01Merge branch 'maint-1.6.0' into maint-1.6.1Libravatar Junio C Hamano1-1/+1
* maint-1.6.0: Documentation: Remove an odd "instead"
2009-04-01Documentation: Remove an odd "instead"Libravatar Holger Weiß1-1/+1
Signed-off-by: Holger Weiß <holger@zedat.fu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-09Implement git clone -vLibravatar Miklos Vajna1-0/+5
The new -v option forces the progressbar, even in case the output is not a terminal. This can be useful if the caller is an IDE or wrapper which wants to scrape the progressbar from stderr and show its information in a different format. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-08-02clone: Add an option to set up a mirrorLibravatar Johannes Schindelin1-1/+4
The command line $ git clone --mirror $URL is now a short-hand for $ git clone --bare $URL $ (cd $(basename $URL) && git remote add --mirror origin $URL) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-25Remove references to git-fetch-pack from "git clone" documentation.Libravatar Steve Haslam1-5/+4
"git clone" no longer calls "git-fetch-pack", so the documentation is a bit stale. Instead, state that the -u option is to be used when accessing a repository over ssh. Signed-off-by: Steve Haslam <shaslam@lastminute.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-3/+3
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-07-01Documentation formatting and cleanupLibravatar Jonathan Nieder1-6/+6
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>
2008-07-01Documentation: be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-1/+1
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>
2008-06-06documentation: move git(7) to git(1)Libravatar Christian Couder1-1/+1
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>
2008-04-22git-clone.txt: Adjust note to --shared for new pruning behavior of git-gcLibravatar Brandon Casey1-4/+9
Since git-gc now always calls prune, even with --auto, unreferenced objects may be removed by more operations than just git-gc. This is important for clones created using --shared or --reference. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13git clone -s documentation: force a new paragraph for the NOTELibravatar Miklos Vajna1-6/+7
It should be loud and clear. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-23git-clone -s: document problems with git gc --pruneLibravatar Miklos Vajna1-0/+8
There is a scenario when using git clone -s and git gc --prune togother is dangerous. Document this. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> 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-11-17Documentation: fix git-clone manpage not to refer to itselfLibravatar Sergei Organov1-0/+1
Signed-off-by: Sergei Organov <osv@javad.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-03git-clone: honor "--" to end argument parsingLibravatar Heikki Orsila1-1/+1
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
2007-11-01git-clone.txt: Improve --depth description.Libravatar Ralf Wildenhues1-3/+3
Avoid abbreviation 'revs', improve the language a bit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-07Documentation / grammer nitLibravatar Mike Ralphson1-1/+1
If we're counting, a smaller number is 'fewer' not 'less' Signed-off-by: Mike Ralphson <mike@abacus.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01git-clone: aggressively optimize local clone behaviour.Libravatar Junio C Hamano1-3/+15
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-12Document long options '--message=<msg>' and '--no-commit'Libravatar Jakub Narebski1-0/+1
Document that '--message=<msg>' is long version of '-m <msg>' in git-commit, and that '--no-checkout' is long version of '-n' in git-clone. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-05Add urls.txt to git-clone man pageLibravatar Andrew Ruder1-2/+5
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-06-09Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Make command description imperative statement, not third-person present.
2007-06-09Make command description imperative statement, not third-person present.Libravatar william pursell1-1/+1
In several of the text messages, the tense of the verb is inconsistent. For example, "Add" vs "Creates". It is customary to use imperative for command description. 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-05-12tiny fix in documentation of git-cloneLibravatar Steffen Prohaska1-1/+1
path in example was missing '../' Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-19git-clone: Sync documentation to usage note.Libravatar Christian Schlotter1-2/+2
Documentation advertises the new `--depth <n>' parameter with an equal sign, while the usage notes (shown after `git-clone --help') do not. If I understood git-clone's source code correctly, the version without the equal sign is correct, which is why this patch syncs documentation to the usage note. Signed-off-by: Christian Schlotter <schlotter@users.sourceforge.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-18Documentation: sync git.txt command list and manual page titleLibravatar Junio C Hamano1-1/+1
Also reorders a handful entries to make each list sorted alphabetically. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-06Describe git-clone's actual behavior in the summaryLibravatar Steven Grimm1-3/+3
If a branch other than "master" is checked out in the origin repository, git-clone makes a local copy of that branch rather than the origin's "master" branch. This patch describes the actual behavior. Signed-off-by: Steven Grimm <koreth@midwinter.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-01Update clone/fetch documentation with --depth (shallow clone) optionLibravatar Junio C Hamano1-1/+11
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31Documentation: update git-clone.txt for clone's new default behaviorLibravatar J. Bruce Fields1-7/+4
Fix a couple remaining references to the origin branch. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16git-clone: lose the traditional 'no-separate-remote' layoutLibravatar Junio C Hamano1-14/+1
Finally. The separate-remote layout is so much more organized than traditional and easier to work with especially when you need to deal with remote repositories with multiple branches and/or you need to deal with more than one remote repositories, and using traditional layout for new repositories simply does not make much sense. Internally we still have code for 1:1 mappings to create a bare clone; that is a good thing and will not go away. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15git-clone documentationLibravatar Quy Tonthat1-1/+1
When --use-separate-remote is used on git-clone, the remote heads are saved under $GIT_DIR/refs/remotes/origin/, not "$GIT_DIR/remotes/origin/" Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-07Documentation: update git-clone man page with new behaviorLibravatar J. Bruce Fields1-13/+12
Update git-clone man page to reflect recent changes (--use-separate-remote default and use of .git/config instead of remotes files), and rewrite introduction. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-04git-clone: Rename --use-immingled-remote option to --no-separate-remoteLibravatar Jakub Narebski1-2/+2
With making --use-separate-remote default when creating non-bare clone, there was need for the flag which would turn off this behavior. It was called --use-immingled-remote. Immingle means to blend, to combine into one, to intermingle, but it is a bit obscure word. I think it would be better to use simply --no-separate-remote as the opposite to --use-separate-remote option to git clone. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-23Make git-clone --use-separate-remote the defaultLibravatar Petr Baudis1-6/+18
We've talked about this for quite some time on the list, and it is a sane thing to do for a repository with an associcated working tree. For somebody who wants to use the traditional layout, there is a backward compatibility option --use-immingled-remote, but it is expected to be removed before the next major release. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-02git-clone documentation didn't mention --origin as equivalent of -oLibravatar Andy Parkins1-0/+1
Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-21Retire git-clone-packLibravatar Junio C Hamano1-2/+2
The program is not used by git-clone since git-fetch-pack was extended to allow its caller do what git-clone-pack alone did, and git-clone was updated to use it. Signed-off-by: Junio C Hamano <junkio@cox.net>