summaryrefslogtreecommitdiff
path: root/git-clone.sh
AgeCommit message (Collapse)AuthorFilesLines
2007-06-08Merge branch 'ar/clone'Libravatar Junio C Hamano1-1/+1
* ar/clone: Fix clone to setup the origin if its name ends with .git
2007-06-07War on whitespaceLibravatar Junio C Hamano1-3/+2
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-06-06Fix clone to setup the origin if its name ends with .gitLibravatar Alex Riesen1-1/+1
The problem is visible when cloning a local repo. The cloned repository will have the origin url setup incorrectly: the origin name will be copied verbatim in origin url of the cloned repository. Normally, the name is to be expanded into absolute path. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-14Fix git-clone buglet for remote case.Libravatar Junio C Hamano1-2/+2
c2f599e09fd0496413d1744b5b89b9b5c223555d introduced a buglet while cloning from a remote URL; we forgot to squelch the unnecessary error message when we try to cd to the given "remote" name, in order to see if it is a local directory. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-10git-clone: don't get fooled by $PWDLibravatar Junio C Hamano1-1/+8
If you have /home/me/git symlink pointing at /pub/git/mine, trying to clone from /pub/git/his/ using relative path would not work as expected: $ cd /home/me $ cd git $ ls ../ his mine $ git clone -l -s -n ../his/stuff.git This is because "cd ../his/stuff.git" done inside git-clone to check if the repository is local is confused by $PWD, which is set to /home/me, and tries to go to /home/his/stuff.git which is different from /pub/git/his/stuff.git. We could probably say "set -P" (or "cd -P") instead, if we know the shell is POSIX, but the way the patch is coded is probably more portable. [jc: this is updated with Andy Whitcroft's improvements] Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-20git-clone: fix dumb protocol transport to clone from pack-pruned refLibravatar Junio C Hamano1-1/+1
This forward-ports a fix from 2986c022 to git-clone. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-28http-fetch: don't use double-slash as directory separator in URLsLibravatar Gerrit Pape1-1/+1
Please see http://bugs.debian.org/409887 http-fetch expected the URL given at the command line to have a trailing slash anyway, and then added '/objects...' when requesting objects files from the http server. Now it doesn't require the trailing slash in <url> anymore, and strips trailing slashes if given nonetheless. Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-19make git clone -q suppress the noise with http fetchLibravatar Chris Wright1-1/+2
We already have -q in git clone. So for those who care to suppress the noise during an http based clone, make -q actually do a quiet http fetch. Signed-off-by: Chris Wright <chrisw@sous-sol.org> Cc: Fernando Herrera <fherrera@onirica.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-24Fixup no-progress for fetch & cloneLibravatar Johannes Schindelin1-1/+1
The intent of the commit 'fetch & clone: do not output progress when not on a tty' was to make fetching and cloning less chatty when output was not redirected (such as in a cron job). However, there was a serious thinko in that commit. It assumed that the client _and_ the server got this update at the same time. But this is obviously not the case, and therefore upload-pack died on seeing the option "--no-progress". This patch fixes that issue by making it a protocol option. So, until your server is updated, you still see the progress, but once the server has this patch, it will be quiet. A minor issue was also fixed: when cloning, the checkout did not heed no_progress. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-19fetch & clone: do not output progress when not on a ttyLibravatar Johannes Schindelin1-2/+4
This adds the option "--no-progress" to fetch-pack and upload-pack, and makes fetch and clone pass this option when stdout is not a tty. While at documenting that option, also document --strict and --timeout options for upload-pack. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-07git-clone --reference: work well with pack-ref'ed reference repositoryLibravatar Junio C Hamano1-35/+21
Earlier we only used loose refs to anchor already existing objects. When cloning from a repository that forked relatively long time ago from the reference repository, this made the want/have exchange by fetch-pack to do unnecessary work. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04git-clone --reference: saner handling of borrowed symrefs.Libravatar Junio C Hamano1-1/+28
When using --reference to borrow objects from a neighbouring repository while cloning, we copy the entire set of refs under temporary "refs/reference-tmp/refs" space and set up the object alternates. However, a textual symref copied this way would not point at the right place, and causes later steps to emit error messages (which is harmless but still alarming). This is most visible when using a clone created with the separate-remote layout as a reference, because such a repository would have refs/remotes/origin/HEAD with 'ref: refs/remotes/origin/master' as its contents. Although we do not create symbolic-link based refs anymore, they have the same problem because they are always supposed to be relative to refs/ hierarchy (we dereference by hand, so it only is good for HEAD and nothing else). In either case, the solution is simply to remove them after copying under refs/reference-tmp; if a symref points at a true ref, that true ref itself is enough to ensure that objects reachable from it do not needlessly get fetched. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31Escape --upload-pack from expr.Libravatar Shawn O. Pearce1-1/+1
Recent commit ae1dffcb28ee89a23f8d2747be65e17c8eab1690 by Junio changed the way --upload-pack was passed around between clone, fetch and ls-remote and modified the handling of the command line parameter parsing. Unfortunately FreeBSD 6.1 insists that the expression expr --upload-pack=git-upload-pack : '-[^=]*=\(.*\)' is illegal, as the --upload-pack option is not supported by their implementation of expr. Elsewhere in Git we use z as a leading prefix of both arguments, ensuring the -- isn't seen by expr. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-29Replace perl code with pure shell codeLibravatar Simon 'corecode' Schubert1-44/+23
Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince1-5/+5
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-24ls-remote and clone: accept --upload-pack=<path> as well.Libravatar Junio C Hamano1-1/+3
This makes them consistent with other commands that take the path to the upload-pack program. We also pass --upload-pack instead of --exec to the underlying fetch-pack, although it is not strictly necessary. [jc: original motivation from Uwe] Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12use 'init' instead of 'init-db' for shipped docs and toolsLibravatar Nicolas Pitre1-1/+1
While 'init-db' still is and probably will always remain a valid git command for obvious backward compatibility reasons, it would be a good idea to move shipped tools and docs to using 'init' instead. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-09git-clone: Make sure the master branch exists before running cat on it.Libravatar Alexandre Julliard1-1/+1
Otherwise we get an error like this on stderr: cat: [...]/.git/refs/remotes/origin/master: No such file or directory which makes it look like git-clone failed. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-28Allow non-fast-forward of remote tracking branches in default cloneLibravatar Junio C Hamano1-1/+1
This changes the default remote.origin.fetch configuration created by git-clone so that it allows non-fast-forward updates. When using the separate-remote layout with reflog enabled, it does not make much sense to refuse to update the remote tracking branch just because some of them do not fast-forward. git-fetch issues warnings on non-fast-forwardness, and the user can peek at what the previous state was using the reflog. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-27Merge branch 'master' into js/shallowLibravatar Junio C Hamano1-45/+30
This is to adjust to: count-objects -v: show number of packs as well. which will break a test in this series. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16git-clone: lose the traditional 'no-separate-remote' layoutLibravatar Junio C Hamano1-46/+12
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-16git-clone: lose the artificial "first" fetch refspecLibravatar Junio C Hamano1-4/+4
Now we lost the "first refspec is the one that is merged by default" rule, there is no reason for clone to list the remote primary branch in the config file explicitly anymore. We still need it for the traditional layout for other reasons, though. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16git-clone: use wildcard specification for tracking branchesLibravatar Junio C Hamano1-17/+30
This stops enumerating the set of branches found on the remote side when a clone was made in the configuration file. Instead, a single entry that maps each remote branch to the local tracking branch for the remote under the same name is created. Doing it this way not only shortens the configuration file, but automatically adjusts to a new branch added on the remote side after the clone is made. Unfortunately this cannot be done for the traditional layout, where we always need to special case the 'master' to 'origin' mapping within the local branch namespace. But that is Ok; it will be going away before v1.5.0. We could also lose the "primary branch" mapping at the beginning, but that has to wait until we implement the "forbid 'git pull' when we do not have branch.$current.merge for the current branch" policy we earlier discussed. That should also be in v1.5.0 Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-06Explicitly add the default "git pull" behaviour to .git/config on cloneLibravatar Andy Parkins1-1/+3
Without any specification in the .git/config file, git-pull will execute "git-pull origin"; which in turn defaults to pull from the first "pull" definition for the remote, "origin". This is a difficult set of defaults to track for a new user, and it's difficult to see what tells git to do this (especially when it is actually hard-coded behaviour). To ameliorate this slightly, this patch explicitly specifies the default behaviour during a clone using the "branch" section of the config. For example, a clone of a typical repository would create a .git/config containing: [remote "origin"] url = proto://host/repo.git fetch = refs/heads/master:refs/remotes/origin/master [branch "master"] remote = origin merge = refs/heads/master The [branch "master"] section is such that there is no change to the functionality of git-pull, but that functionality is now explicitly documented. Signed-off-by: Andy Parkins <andyparkins@gmail.com>
2006-12-06Merge Libravatar Junio C Hamano1-5/+5
2006-12-04git-clone: Rename --use-immingled-remote option to --no-separate-remoteLibravatar Jakub Narebski1-3/+3
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-27Use .git/config for storing "origin" shortcut repositoryLibravatar Andy Parkins1-5/+5
Rather than use a separate config .git/remotes/ for remote shortcuts, this patch adds the analagous definitions to .git/config using git-repo-config calls. For example what was previously .git/remotes/origin URL: proto://host/path Pull: refs/heads/master:refs/heads/origin Is now added to .git/config as [remote "origin"] url = proto://host/path fetch = refs/heads/master:refs/heads/origin Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-24git-clone: stop dumb protocol from copying refs outside heads/ and tags/.Libravatar Junio C Hamano1-0/+4
Most notably, the original code first copied refs/remotes/ that remote side had to local, and overwrote them by mapping refs/heads/ from the remote when a dumb protocol transport was used. This makes the clone behaviour by dumb protocol in line with the git native and rsync transports. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-24allow cloning a repository "shallowly"Libravatar Johannes Schindelin1-3/+16
By specifying a depth, you can now clone a repository such that all fetched ancestor-chains' length is at most "depth". For example, if the upstream repository has only 2 branches ("A" and "B"), which are linear, and you specify depth 3, you will get A, A~1, A~2, A~3, B, B~1, B~2, and B~3. The ends are automatically made shallow commits. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-23Make git-clone --use-separate-remote the defaultLibravatar Petr Baudis1-7/+7
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-10-23Merge branch 'maint'Libravatar Junio C Hamano1-1/+2
* maint: gitweb: Fix setting $/ in parse_commit() daemon: do not die on older clients. xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header. git-clone: honor --quiet Documentation for the [remote] config prune-packed: Fix uninitialized variable.
2006-10-23git-clone: honor --quietLibravatar Jim Meyering1-1/+2
I noticed that a cron-launched "git-clone --quiet" was generating progress output to standard error -- and thus always spamming me. The offending output was due to git-clone invoking git-read-tree with its undocumented -v option. This change turns off "-v" for --quiet. Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-20git-clone: define die() and use it.Libravatar Dmitry V. Levin1-37/+24
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-14clone: the given repository dir should be relative to $PWDLibravatar Yasushi SHOJI1-1/+1
the repository argument for git-clone should be relative to $PWD instead of the given target directory. The old behavior gave us surprising success and you need a few minute to know why it worked. GIT_DIR is already exported so no need to cd into $D. And this makes $PWD for git-fetch-pack, which is the actual command to take the given repository dir, the same as git-clone. Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-28http/ftp: optionally ask curl to not use EPSV commandLibravatar Sasha Khapyorsky1-0/+4
If http.noEPSV config variable is defined and true, or if GIT_CURL_FTP_NO_EPSV environment variable is defined, disable using of EPSV ftp command (PASV will be used instead). This is helpful with some "poor" ftp servers which does not support EPSV mode. Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-13Trivial support for cloning and fetching via ftp://.Libravatar Sasha Khapyorsky1-1/+1
This adds trivial support for cloning and fetching via ftp://. Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-07handle https:// protocol in git-cloneLibravatar Michael Krelin1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-02Ensure git-clone exits with error if perl script fails.Libravatar Ramsay Allan Jones1-2/+3
This helps tests 5400,5600,5700,5710 "fail correctly" rather than give some false positives. Also ensure cleanup actions in exit trap work correctly even if user has alias rm='rm -i'. Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-13fetch/clone: check return status from ls-remoteLibravatar Junio C Hamano1-2/+2
Some callers of ls-remote did not check its return status.
2006-07-08Using 'perl' in *.shLibravatar Michal Rokos1-1/+1
Some GIT's shell script are using bare 'perl' for perl invocation. Use @@PERL@@ symbol and replace it with PERL_PATH_SQ everywhere. Signed-off-by: Michal Rokos <michal.rokos@nextsoft.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27Fix expr usage for FreeBSDLibravatar Dennis Stosberg1-1/+1
Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-10git-clone: fix --bare over dumb-httpLibravatar Junio C Hamano1-6/+2
It left an extra .git/ directory under the target directory by mistake. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-08git-clone: fix duplicated "master" in $GIT_DIR/remotes/originLibravatar Junio C Hamano1-5/+10
Under --use-separate-remote we ended up duplicating the branch remote HEAD pointed at in $GIT_DIR/remotes/origin file. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-28Let git-clone to pass --template=dir option to git-init-db.Libravatar Junio C Hamano1-2/+8
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-22Problem: 'trap...exit' causes error message when /bin/sh is ash.Libravatar Yakov Lerner1-2/+2
Problem: 'trap...exit' causes error message when /bin/sh is ash. Fix: Change 'trap...exit' to 'trap...0' like in other scripts. Signed-off-by: Yakov Lerner <iler.ml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-07clone: don't clone the info/alternates fileLibravatar Martin Waitz1-5/+1
Now that the cloned alternates file is parsed, too we don't need to copy it into our new repository, we just reference it. Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-07clone: keep --reference even with -l -sLibravatar Martin Waitz1-1/+1
Both -l -s and --reference update objects/info/alternates and used to write over each other. Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-13Shell utilities: Guard against expr' magic tokens.Libravatar Mark Wooding1-3/+3
Some words, e.g., `match', are special to expr(1), and cause strange parsing effects. Track down all uses of expr and mangle the arguments so that this isn't a problem. Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-02git-clone: fix handling of upsteram whose HEAD does not point at master.Libravatar Junio C Hamano1-19/+28
When cloning from a remote repository that has master, main, and origin branches _and_ with the HEAD pointing at main branch, we did quite confused things during clone. So this cleans things up. The behaviour is a bit different between separate remotes/ layout and the mixed branches layout. The newer layout with $GIT_DIR/refs/remotes/$origin/, things are simpler and more transparent: - remote branches are copied to refs/remotes/$origin/. - HEAD points at the branch with the same name as the remote HEAD points at, and starts at where the remote HEAD points at. - $GIT_DIR/remotes/$origin file is set up to fetch all remote branches, and merge the branch HEAD pointed at at the time of the cloning. Everything-in-refs/heads layout was the more confused one, but cleaned up like this: - remote branches are copied to refs/heads, but the branch "$origin" is not copied, instead a copy of the branch the remote HEAD points at is created there. - HEAD points at the branch with the same name as the remote HEAD points at, and starts at where the remote HEAD points at. - $GIT_DIR/remotes/$origin file is set up to fetch all remote branches except "$origin", and merge the branch HEAD pointed at at the time of the cloning. With this, the remote has master, main and origin, and its HEAD points at main, you could: git clone $URL --origin upstream to use refs/heads/upstream as the tracking branch for remote "main", and your primary working branch will also be "main". "master" and "origin" are used to track the corresponding remote branches and with this setup they do not have any special meaning. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-30git-clone: exit early if repo isn't specifiedLibravatar Yasushi SHOJI1-2/+8
git-clone without a repo isn't useful at all. print message and get out asap. This patch also move the variable 'local' to where other variables are initialized. Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: Junio C Hamano <junkio@cox.net>