summaryrefslogtreecommitdiff
path: root/builtin/clone.c
AgeCommit message (Collapse)AuthorFilesLines
2013-06-02Merge branch 'nd/clone-local-with-colon'Libravatar Junio C Hamano1-0/+2
"git clone foo/bar:baz" cannot be a request to clone from a remote over git-over-ssh specified in the scp style. Detect this case and clone from a local repository at "foo/bar:baz". * nd/clone-local-with-colon: clone: allow cloning local paths with colons in them
2013-05-29Merge branch 'mh/packed-refs-various'Libravatar Junio C Hamano1-1/+0
Update reading and updating packed-refs file, correcting corner case bugs. * mh/packed-refs-various: (33 commits) refs: handle the main ref_cache specially refs: change do_for_each_*() functions to take ref_cache arguments pack_one_ref(): do some cheap tests before a more expensive one pack_one_ref(): use write_packed_entry() to do the writing pack_one_ref(): use function peel_entry() refs: inline function do_not_prune() pack_refs(): change to use do_for_each_entry() refs: use same lock_file object for both ref-packing functions pack_one_ref(): rename "path" parameter to "refname" pack-refs: merge code from pack-refs.{c,h} into refs.{c,h} pack-refs: rename handle_one_ref() to pack_one_ref() refs: extract a function write_packed_entry() repack_without_ref(): write peeled refs in the rewritten file t3211: demonstrate loss of peeled refs if a packed ref is deleted refs: change how packed refs are deleted search_ref_dir(): return an index rather than a pointer repack_without_ref(): silence errors for dangling packed refs t3210: test for spurious error messages for dangling packed refs refs: change the internal reference-iteration API refs: extract a function peel_entry() ...
2013-05-07clone: allow cloning local paths with colons in themLibravatar Nguyễn Thái Ngọc Duy1-0/+2
Usually "foo:bar" is interpreted as an ssh url. This patch allows to clone from such paths by putting at least one slash before the colon (i.e. /path/to/foo:bar or just ./foo:bar). file://foo:bar should also work, but local optimizations are off in that case, which may be unwanted. While at there, warn the users about --local being ignored in this case. Reported-by: William Giokas <1007380@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-01pack-refs: merge code from pack-refs.{c,h} into refs.{c,h}Libravatar Michael Haggerty1-1/+0
pack-refs.c doesn't contain much code, and the code it does contain is closely related to reference handling. Moreover, there is some duplication between pack_refs() and repack_without_ref(). Therefore, merge pack-refs.c into refs.c and pack-refs.h into refs.h. The code duplication will be addressed in future commits. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-28Merge branch 'jk/check-corrupt-objects-carefully'Libravatar Junio C Hamano1-1/+1
* jk/check-corrupt-objects-carefully: clone: Make the 'junk_mode' symbol a file static
2013-04-28clone: Make the 'junk_mode' symbol a file staticLibravatar Ramsay Jones1-1/+1
Sparse issues an "'junk_mode' not declared. Should it be static?" warning. In order to suppress the warning, since this symbol does not need more than file visibility, we simply add the static modifier to its declaration. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-09clone: Allow repo using gitfile as a referenceLibravatar Aaron Schrab1-2/+12
Try reading gitfile files when processing --reference options to clone. This will allow, among other things, using a submodule checked out with a recent version of git as a reference repository without requiring the user to have internal knowledge of submodule layout. Signed-off-by: Aaron Schrab <aaron@schrab.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-08clone: Fix error message for reference repositoryLibravatar Aaron Schrab1-1/+1
Do not report that an argument to clone's --reference option is not a local directory. Nothing checks for the existence or type of the path as supplied by the user; checks are only done for particular contents of the supposed directory, so we have no way to know the status of the supplied path. Telling the user that a directory doesn't exist when that isn't actually known may lead him or her on the wrong path to finding the problem. Instead just state that the entered path is not a local repository which is really all that is known about it. It could be more helpful to state the actual paths which were checked, but I believe that giving a good description of that would be too verbose for a simple error message and would be too dependent on implementation details. Signed-off-by: Aaron Schrab <aaron@schrab.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-29clone: leave repo in place after checkout errorsLibravatar Jeff King1-1/+24
If we manage to clone a remote repository but run into an error in the checkout, it is probably sane to leave the repo directory in place. That lets the user examine the situation without spending time to re-clone from the remote (which may be a lengthy process). Rather than try to convert each die() from the checkout code path into an error(), we simply set a flag that tells the "remove_junk" atexit function to print a helpful message and leave the repo in place. Note that the test added in this patch actually passes without the code change. The reason is that the cleanup code is buggy; we chdir into the working tree for the checkout, but still may use relative paths to remove the directories (which means if you cloned into "foo", we would accidentally remove "foo" from the working tree!). There's no point in fixing it now, since this patch means we will never try to remove anything after the chdir, anyway. [jc: replaced the message with a more succinct version from Jonathan] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27clone: run check_everything_connectedLibravatar Jeff King1-0/+26
When we fetch from a remote, we do a revision walk to make sure that what we received is connected to our existing history. We do not do the same check for clone, which should be able to check that we received an intact history graph. The upside of this patch is that it will make clone more resilient against propagating repository corruption. The downside is that we will now traverse "rev-list --objects --all" down to the roots, which may take some time (it is especially noticeable for a "--local --bare" clone). Note that we need to adjust t5710, which tries to make such a bogus clone. Rather than checking after the fact that our clone is bogus, we can simplify it to just make sure "git clone" reports failure. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27clone: die on errors from unpack_treesLibravatar Jeff King1-1/+2
When clone is populating the working tree, it ignores the return status from unpack_trees; this means we may report a successful clone, even when the checkout fails. When checkout fails, we may want to leave the $GIT_DIR in place, as it might be possible to recover the data through further use of "git checkout" (e.g., if the checkout failed due to a transient error, disk full, etc). However, we already die on a number of other checkout-related errors, so this patch follows that pattern. In addition to marking a now-passing test, we need to adjust t5710, which blindly assumed it could make bogus clones of very deep alternates hierarchies. By using "--bare", we can avoid it actually touching any objects. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-25Merge branch 'nd/clone-no-separate-git-dir-with-bare' into maintLibravatar Junio C Hamano1-0/+2
* nd/clone-no-separate-git-dir-with-bare: clone: forbid --bare --separate-git-dir <dir>
2013-02-01Merge branch 'jc/no-git-config-in-clone'Libravatar Junio C Hamano1-9/+0
We stopped paying attention to $GIT_CONFIG environment that points at a single configuration file from any command other than "git config" quite a while ago, but "git clone" internally set, exported, and then unexported the variable during its operation unnecessarily. * jc/no-git-config-in-clone: clone: do not export and unexport GIT_CONFIG
2013-01-21Merge branch 'nd/clone-no-separate-git-dir-with-bare'Libravatar Junio C Hamano1-0/+2
Forbid a useless combination of options to "git clone". * nd/clone-no-separate-git-dir-with-bare: clone: forbid --bare --separate-git-dir <dir>
2013-01-14Merge branch 'jl/interrupt-clone-remove-separate-git-dir' into maintLibravatar Junio C Hamano1-1/+3
When "git clone --separate-git-dir=$over_there" is interrupted, it failed to remove the real location of the $GIT_DIR it created. This was most visible when interrupting a submodule update. * jl/interrupt-clone-remove-separate-git-dir: clone: support atomic operation with --separate-git-dir
2013-01-11clone: do not export and unexport GIT_CONFIGLibravatar Junio C Hamano1-9/+0
Earlier, dc87183 (use GIT_CONFIG only in "git config", not other programs, 2008-06-30) made sure that the environment variable is never used outside "git config", but "git clone", after creating a directory for the new repository and until the init_db() function populates its .git/ directory, exported the variable for no good reason. No hook will run from init_db() and more importantly no hook can run until init_db() finishes creation of the new repository, so it cannot be used by any invocation of "git config" by definition. Stop doing the useless export/unexport. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-10clone: forbid --bare --separate-git-dir <dir>Libravatar Nguyễn Thái Ngọc Duy1-0/+2
The --separate-git-dir option was introduced to make it simple to put the git directory somewhere outside the worktree, for example when cloning a repository for use as a submodule. It was not intended for use when creating a bare repository. In that case there is no worktree and it is more natural to directly clone the repository and create a .git file as separate steps: git clone --bare /path/to/repo.git bar.git printf 'gitdir: bar.git\n' >foo.git Forbid the combination, making the command easier to explain. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-10Merge branch 'jl/interrupt-clone-remove-separate-git-dir'Libravatar Junio C Hamano1-1/+3
When "git clone --separate-git-dir" is interrupted, we failed to remove the real location we created the repository. * jl/interrupt-clone-remove-separate-git-dir: clone: support atomic operation with --separate-git-dir
2013-01-05clone: support atomic operation with --separate-git-dirLibravatar Jens Lehmann1-1/+3
Since b57fb80a7d (init, clone: support --separate-git-dir for .git file) git clone supports the --separate-git-dir option to create the git dir outside the work tree. But when that option is used, the git dir won't be deleted in case the clone fails like it would be without this option. This makes clone lose its atomicity as in case of a failure a partly set up git dir is left behind. A real world example where this leads to problems is when "git submodule update" fails to clone a submodule and later calls to "git submodule update" stumble over the partially set up git dir and try to revive the submodule from there, which then fails with a not very user friendly error message. Fix that by updating the junk_git_dir variable (used to remember if and what git dir should be removed in case of failure) to the new value given with the --seperate-git-dir option. Also add a test for this to t5600 (and while at it fix the former last test to not cd into a directory to test for its existence but use "test -d" instead). Reported-by: Manlio Perillo <manlio.perillo@gmail.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-08Merge branch 'rt/maint-clone-single' into maintLibravatar Junio C Hamano1-14/+51
A repository created with "git clone --single" had its fetch refspecs set up just like a clone without "--single", leading the subsequent "git fetch" to slurp all the other branches, defeating the whole point of specifying "only this branch". * rt/maint-clone-single: clone --single: limit the fetch refspec to fetched branch
2012-10-01Merge branch 'rt/maint-clone-single'Libravatar Junio C Hamano1-14/+51
Running "git fetch" in a repository made with "git clone --single" slurps all the branches, defeating the point of "--single". * rt/maint-clone-single: clone --single: limit the fetch refspec to fetched branch
2012-09-20clone --single: limit the fetch refspec to fetched branchLibravatar Ralf Thielow1-14/+51
After running "git clone --single", the resulting repository has the usual default "+refs/heads/*:refs/remotes/origin/*" wildcard fetch refspec installed, which means that a subsequent "git fetch" will end up grabbing all the other branches. Update the fetch refspec to cover only the singly cloned ref instead to correct this. That means: If "--single" is used without "--branch" or "--mirror", the fetch refspec covers the branch on which remote's HEAD points to. If "--single" is used with "--branch", it'll cover only the branch specified in the "--branch" option. If "--single" is combined with "--mirror", then it'll cover all refs of the cloned repository. If "--single" is used with "--branch" that specifies a tag, then it'll cover only the ref for this tag. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-14Merge branch 'rj/path-cleanup'Libravatar Junio C Hamano1-2/+2
* rj/path-cleanup: Call mkpathdup() rather than xstrdup(mkpath(...)) Call git_pathdup() rather than xstrdup(git_path("...")) path.c: Use vsnpath() in the implementation of git_path() path.c: Don't discard the return value of vsnpath() path.c: Remove the 'git_' prefix from a file scope function
2012-09-04Call mkpathdup() rather than xstrdup(mkpath(...))Libravatar Ramsay Jones1-2/+2
In addition to updating the xstrdup(mkpath(...)) call sites with mkpathdup(), we also fix a memory leak (in merge_3way()) caused by neglecting to free the memory allocated to the 'base_name' variable. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-20i18n: clone: mark parseopt strings for translationLibravatar Nguyễn Thái Ngọc Duy1-28/+28
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-22Merge branch 'ar/clone-honor-umask-at-top' into maintLibravatar Junio C Hamano1-1/+1
A handful of files and directories we create had tighter than necessary permission bits when the user wanted to have group writability (e.g. by setting "umask 002"). * ar/clone-honor-umask-at-top: add: create ADD_EDIT.patch with mode 0666 rerere: make rr-cache fanout directory honor umask Restore umasks influence on the permissions of work tree created by clone
2012-07-15Merge branch 'ar/clone-honor-umask-at-top'Libravatar Junio C Hamano1-1/+1
A handful of files and directories we create had tighter than necessary permission bits when the user wanted to have group writability (e.g. by setting "umask 002"). * ar/clone-honor-umask-at-top: add: create ADD_EDIT.patch with mode 0666 rerere: make rr-cache fanout directory honor umask Restore umasks influence on the permissions of work tree created by clone
2012-07-09Restore umasks influence on the permissions of work tree created by cloneLibravatar Alex Riesen1-1/+1
The original version of the git-clone just used mkdir(1) to create the working directories. The version rewritten in C creates all directories inside the working tree by using the mode argument of 0777 when calling mkdir(2) to let the umask take effect. But the top-level directory of the working tree is created by passing the mode argument of 0755 to mkdir(2), which results in an overly tight restriction if the user wants to make directories group writable with a looser umask like 002. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-04Merge branch 'nd/clone-single-fix'Libravatar Junio C Hamano1-2/+5
"git clone --single-branch" to clone a single branch did not limit the cloning to the specified branch. * nd/clone-single-fix: clone: fix ref selection in --single-branch --branch=xxx
2012-06-22clone: fix ref selection in --single-branch --branch=xxxLibravatar Nguyễn Thái Ngọc Duy1-2/+5
- do not fetch HEAD - do not also fetch refs following "xxx" Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-30clone: allow --no-local to turn off local optimizationsLibravatar Jeff King1-5/+5
This is basically the same as using "file://", but is a little less subtle for the end user. It also allows relative paths to be specified. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-07Merge branch 'ef/maint-1.7.6-clone-progress-fix' into ↵Libravatar Junio C Hamano1-1/+1
ef/maint-clone-progress-fix By Erik Faye-Lund * ef/maint-1.7.6-clone-progress-fix: clone: fix progress-regression
2012-05-07clone: fix progress-regressionLibravatar Erik Faye-Lund1-1/+1
In 5bd631b3 ("clone: support multiple levels of verbosity"), the default behavior to show progress of the implicit checkout in the clone-command regressed so that progress was only shown if the verbose-option was specified. Fix this by making option_verbosity == 0 output progress as well. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-21Merge branch 'cb/transfer-no-progress' into maintLibravatar Junio C Hamano1-3/+3
* cb/transfer-no-progress: push/fetch/clone --no-progress suppresses progress output
2012-02-21Merge branch 'jk/git-dir-lookup' into maintLibravatar Junio C Hamano1-2/+2
* jk/git-dir-lookup: standardize and improve lookup rules for external local repos
2012-02-20Merge branch 'cb/transfer-no-progress'Libravatar Junio C Hamano1-3/+3
* cb/transfer-no-progress: push/fetch/clone --no-progress suppresses progress output
2012-02-14Merge branch 'jk/git-dir-lookup'Libravatar Junio C Hamano1-2/+2
* jk/git-dir-lookup: standardize and improve lookup rules for external local repos
2012-02-13push/fetch/clone --no-progress suppresses progress outputLibravatar Clemens Buchacher1-3/+3
By default, progress output is disabled if stderr is not a terminal. The --progress option can be used to force progress output anyways. Conversely, --no-progress does not force progress output. In particular, if stderr is a terminal, progress output is enabled. This is unintuitive. Change --no-progress to force output off. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-12clone: do not add alternate references to extra_refsLibravatar Michael Haggerty1-12/+0
Alternate references are directly (and now, correctly) handled by fetch-pack, so there is no need to inform fetch-pack about them via the extra_refs back channel. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-12clone.c: move more code into the "if (refs)" conditionalLibravatar Michael Haggerty1-19/+20
The bahavior of a bunch of code before the "if (refs)" statement also depends on whether refs is set, so make the logic clearer by shifting this code into the if statement. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-02standardize and improve lookup rules for external local reposLibravatar Jeff King1-2/+2
When you specify a local repository on the command line of clone, ls-remote, upload-pack, receive-pack, or upload-archive, or in a request to git-daemon, we perform a little bit of lookup magic, doing things like looking in working trees for .git directories and appending ".git" for bare repos. For clone, this magic happens in get_repo_path. For everything else, it happens in enter_repo. In both cases, there are some ambiguous or confusing cases that aren't handled well, and there is one case that is not handled the same by both methods. This patch tries to provide (and test!) standard, sensible lookup rules for both code paths. The intended changes are: 1. When looking up "foo", we have always preferred a working tree "foo" (containing "foo/.git" over the bare "foo.git". But we did not prefer a bare "foo" over "foo.git". With this patch, we do so. 2. We would select directories that existed but didn't actually look like git repositories. With this patch, we make sure a selected directory looks like a git repo. Not only is this more sensible in general, but it will help anybody who is negatively affected by change (1) negatively (e.g., if they had "foo.git" next to its separate work tree "foo", and expect to keep finding "foo.git" when they reference "foo"). 3. The enter_repo code path would, given "foo", look for "foo.git/.git" (i.e., do the ".git" append magic even for a repo with working tree). The clone code path did not; with this patch, they now behave the same. In the unlikely case of a working tree overlaying a bare repo (i.e., a ".git" directory _inside_ a bare repo), we continue to treat it as a working tree (prefering the "inner" .git over the bare repo). This is mainly because the combination seems nonsensical, and I'd rather stick with existing behavior on the off chance that somebody is relying on it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-31Merge branch 'nd/clone-detached'Libravatar Junio C Hamano1-125/+182
* nd/clone-detached: clone: fix up delay cloning conditions push: do not let configured foreign-vcs permanently clobbered clone: print advice on checking out detached HEAD clone: allow --branch to take a tag clone: refuse to clone if --branch points to bogus ref clone: --branch=<branch> always means refs/heads/<branch> clone: delay cloning until after remote HEAD checking clone: factor out remote ref writing clone: factor out HEAD update code clone: factor out checkout code clone: write detached HEAD in bare repositories t5601: add missing && cascade
2012-01-29Merge branch 'mh/ref-clone-without-extra-refs'Libravatar Junio C Hamano1-2/+1
* mh/ref-clone-without-extra-refs: write_remote_refs(): create packed (rather than extra) refs add_packed_ref(): new function in the refs API. ref_array: keep track of whether references are sorted pack_refs(): remove redundant check
2012-01-24clone: fix up delay cloning conditionsLibravatar Nguyễn Thái Ngọc Duy1-6/+14
6f48d39 (clone: delay cloning until after remote HEAD checking - 2012-01-16) allows us to perform some checks on remote refs before the actual cloning happens. But not all transport types support this. Remote helper with "import" capability will not return complete ref information until fetch is performed and therefore the clone cannot be delayed. foreign_vcs field in struct remote was used to detect this kind of transport and save the result. This is a mistake because foreign_vcs is designed to override url-based transport detection. As a result, if the same "struct transport *" object is used on many different urls and one of them attached remote transport, the following urls will be mistakenly attached to the same transport. This fault is worked around by dad0b3d (push: do not let configured foreign-vcs permanently clobbered - 2012-01-23) To fix this, detect incomplete refs from transport_get_remote_refs() by SHA-1. Incomplete ones must have null SHA-1 (*). Then revert changes related to foreign_cvs field in 6f48d39 and dad0b3d. A good thing from this change is that cloning smart http transport can also be delayed. Earlier it falls into the same category "remote transport, no delay". (*) Theoretically if one of the remote refs happens to have null SHA-1, it will trigger false alarm and the clone will not be delayed. But that chance may be too small for us to pay attention to. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-17write_remote_refs(): create packed (rather than extra) refsLibravatar Michael Haggerty1-2/+1
write_remote_refs() creates new packed refs from references obtained from the remote repository, which is "out of thin air" as far as the local repository is concerned. Previously it did this by creating "extra" refs, then calling pack_refs() to bake them into the packed-refs file. Instead, create packed refs (in the packed reference cache) directly, then call pack_refs(). Aside from being more logical, this is another step towards removing extra refs entirely. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-16clone: print advice on checking out detached HEADLibravatar Nguyễn Thái Ngọc Duy1-1/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-16clone: allow --branch to take a tagLibravatar Nguyễn Thái Ngọc Duy1-1/+19
Because a tag ref cannot be put to HEAD, HEAD will become detached. This is consistent with "git checkout <tag>". This is mostly useful in shallow clone, where it allows you to clone a tag in addtion to branches. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-16clone: refuse to clone if --branch points to bogus refLibravatar Nguyễn Thái Ngọc Duy1-8/+4
It's possible that users make a typo in the branch name. Stop and let users recheck. Falling back to remote's HEAD is not documented any way. Except when using remote helper, the pack has not been transferred at this stage yet so we don't waste much bandwidth. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-16clone: --branch=<branch> always means refs/heads/<branch>Libravatar Nguyễn Thái Ngọc Duy1-14/+16
It does not make sense to look outside refs/heads for HEAD's target (src_ref_prefix can be set to "refs/" if --mirror is used) because ref code only allows symref in form refs/heads/... Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-16clone: delay cloning until after remote HEAD checkingLibravatar Nguyễn Thái Ngọc Duy1-27/+27
This gives us an opportunity to abort the command during remote HEAD check without wasting much bandwidth. Cloning with remote-helper remains before the check because the remote helper updates mapped_refs, which is necessary for remote ref checks. foreign_vcs field is used to indicate the transport is handled by remote helper. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>