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>
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>
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>
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>
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>
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>
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>
Recent commit ae1dffcb28 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* 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.
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
git-clone currently take option '-o' to specify origin. this patch
makes git-clone to take double-dashed option '--origin' and other
abbreviations in addtion to the current single-dashed option.
[jc: with minor fixups]
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The traditional one created refs/origin by mistake, not
refs/heads/origin. Also it mistakenly failed to prevent
$origin from being listed twice in remotes/origin file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This matches c51d13692d commit to
record the primary branch of the remote with a symbolic ref
remotes/$origin/HEAD. The user can later change it to point at
different branch to change the meaning of "$origin" shorthand.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This builds on top of the previous one.
* --use-separate-remote uses .git/refs/remotes/$origin/
directory to keep track of the upstream branches.
* The $origin above defaults to "origin" as usual, but the
existing "-o $origin" option can be used to override it.
I am not yet convinced if we should make "$origin" the synonym to
"refs/remotes/$origin/$name" where $name is the primary branch
name of $origin upstream, nor if so how we should decide which
upstream branch is the primary one, but that is more or less
orthogonal to what the clone does here.
Signed-off-by: Junio C Hamano <junkio@cox.net>
