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>
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>
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>
This does two things.
* A new flag --reference can be used to name a local repository
that is to be used as an alternate. This is in response to
an inquiry by James Cloos in the message on the list
<m3r74ykue7.fsf@lugabout.cloos.reno.nv.us>.
* A new flag --use-separate-remote stops contaminating local
branch namespace by upstream branch names. The upstream
branch heads are copied in .git/refs/remotes/ instead of
.git/refs/heads/ and .git/remotes/origin file is set up to
reflect this as well. It requires to have fetch/pull update
to understand .git/refs/remotes by Eric Wong to further
update the repository cloned this way.
For the former change, git-fetch-pack is taught a new flag --all
to fetch from all the remote heads. Nobody uses the git-clone-pack
with this change, so we could deprecate the command, but removal
of the command will be left to a separate round.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In windows you cannot remove current or opened directory,
an opened file, a running program, a loaded library, etc...
[jc: signoffs? With a minor quoting fix.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
This implements "eye candy" similar to the pack-object/unpack-object
to entertain users while a large tree is being checked out after
a clone or a pull.
Signed-off-by: Junio C Hamano <junkio@cox.net>
To some cpio's, -a and -m options are mutually exclusive. Use only -m.
Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If Git is compiled with NO_CURL=YesPlease and one tries to
clone a http repository, git-clone tries to call the curl
binary. This trivial patch prints an error instead in such
situation.
Signed-off-by: Fernando J. Pereda <ferdy@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If repo has the form <host>:<path> and <path> doesn't contain a slash, the
cloned repository is named "<host>:<path>", instead of "<path>" only.
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new option --naked is to help creating a naked repository
for public consumption.
$ git clone -l -s --naked \
/pub/scm/.../torvalds/linux-2.6.git subproj-2.6.git
is equivalent to this sequence:
$ git clone -l -s -n /pub/scm/.../torvalds/linux-2.6.git temp
$ mv temp/.git subproj-2.6.git
$ rmdir temp
Signed-off-by: Junio C Hamano <junkio@cox.net>
Underlying http-fetch is supposed to be capable of handling
packed repositories just fine, so no need to special case it in
the wrapper script.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, git-clone stored upstream's master in the branch named 'origin',
possibly overwriting an existing such branch.
Now you can change it by calling git-clone with '-o <other_name>'.
[jc: added ref format check, subdirectory safety, documentation
and usage string.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When clone-pack has trouble with the remote, it dies unfriendly
"EOF" error message. We cannot tell the reason why it failed
from the local end; it could be that the repository did not
exist, or configured not to serve over git-daemon, or a network
failure. At least, saying clone-pack failed makes it a bit more
meaningful.
I am not convinced yet that removing the newly created directory
is the right thing to do, so this commit leaves the new
directory behind.
Reported by Sam Ravnborg.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The "--shared" option to git-clone is silently ignored if "--local" is
not specified. The manual doesn't mention such dependency. Make
"--shared" imply "--local".
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix a typo: We do not want to run the directory as command,
and want to terminate if the directory exists
Additionally, update the usage message
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano