This is a stop-gap to work around problem with git-init without
intrusive changes.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

If GIT_WORK_TREE is set git-clone will use that path for the
working tree.
Signed-off-by: NMatthias Lederhofer <matled@gmx.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMatthias Lederhofer <matled@gmx.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This uses the remove-dashes target to replace "git-frotz" to "git frotz".
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-clone supports cloning from a repo with detached HEAD,
but if this HEAD is not behind any branch tip then it
would not have been fetched over dumb http, resulting in a

	fatal: Not a valid object name HEAD

Since 928c210a, this would also happen on a http repo
with a HEAD that is a symbolic link where someone has
forgotton to run update-server-info.
Signed-off-by: NSven Verdoolaege <skimo@liacs.nl>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Now that git-init has an option to quiet itself, use it if the -q
option was specified on the clone command line.
Signed-off-by: NJeffrey C. Ollie <jeff@ocjtech.us>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If the remote repository does not have a "current branch", git-clone
was confused and did not set up the resulting new repository
correctly.  It did not reset HEAD from the default 'master', and did
not write the SHA1 to the master branch.
Signed-off-by: NNanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJunio C Hamano <gitster@pobox.com>

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: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

c2f599e0 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: NJunio C Hamano <junkio@cox.net>

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: NJunio C Hamano <junkio@cox.net>

This forward-ports a fix from 2986c022 to git-clone.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NChris Wright <chrisw@sous-sol.org>
Cc: Fernando Herrera <fherrera@onirica.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJunio C Hamano <junkio@cox.net>

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: NJunio C Hamano <junkio@cox.net>

Recent commit ae1dffcb 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: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NSimon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NTom Prince <tom.prince@ualberta.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJunio C Hamano <junkio@cox.net>

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: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NAlexandre Julliard <julliard@winehq.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJunio C Hamano <junkio@cox.net>

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: NJunio C Hamano <junkio@cox.net>

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: NJunio C Hamano <junkio@cox.net>

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: NJunio C Hamano <junkio@cox.net>

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: NAndy Parkins <andyparkins@gmail.com>

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: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NAndy Parkins <andyparkins@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJunio C Hamano <junkio@cox.net>

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: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJim Meyering <jim@meyering.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NDmitry V. Levin <ldv@altlinux.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NYasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NSasha Khapyorsky <sashak@voltaire.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds trivial support for cloning and fetching via ftp://.
Signed-off-by: NSasha Khapyorsky <sashak@voltaire.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>