Removal of them is needed regardless of errors. The original
code had the removal outside of the process which sets the flag
to tell the later step what to remove, but it runs as a
downstream of a pipeline and its effect was lost.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio rightly pointed out that the --reflog-action parameter
was starting to get out of control, as most porcelain code
needed to hand it to other porcelain and plumbing alike to
ensure the reflog contained the top-level user action and
not the lower-level actions it invoked.
At Junio's suggestion we are introducing the new set_reflog_action
function to all shell scripts, allowing them to declare early on
what their default reflog name should be, but this setting only
takes effect if the caller has not already set the GIT_REFLOG_ACTION
environment variable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The remote server might not want to tell why it doesn't like us for
security reasons, but let's make the client report such error in a bit
less confusing way. The remote failure remains a mystery, but the local
message might be a bit less so.
[jc: with a gentle wording updates from Andy Parkins]
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When checking which tags to fetch, the old code used to call
git-show-ref --verify for each remote tag. Since reading even
packed refs is not a cheap operation when there are a lot of
local refs, the code became quite slow.
This fixes it by teaching git-show-ref to filter out existing
refs using a new mode of operation of git-show-ref.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When update_local_ref() refuses to update a branch head due to
fast-forward check, it was not propagated properly in the call
chain and the command did not exit with non-zero status as a
result.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise fetching the tags could also fetch commits up to the
specified depth, which isn't the expected behavior.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now, by saying "git fetch -depth <n> <repo>" you can deepen
a shallow repository.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, commit walkers downloaded loose refs from refs/ hierarchy
of the remote side to find where to start walking; this would
not work for a repository whose refs are packed and then pruned.
With the previous change, we have ls-remote output from the
remote in-core; we can use the value from there without
requiring loose refs anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This will become necessary to update the dumb protocol
transports to fetch from a repository with packed and then
pruned tags.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This side-ports commit fd19f620 from Cogito, in which I fixed
exactly the same bug. Somehow nobody noticed this for a long
time in git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes both git-fetch and git-push (fetch-pack and receive-pack)
safe against a possible race with aparallel git-repack -a -d that could
prune the new pack while it is not yet referenced, and remove the .keep
file after refs have been updated.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have supported https:// protocol for some time and in 1.4.3
added ftp:// protocol. The transfer were still reported to be
over http.
[jc: Tuncer used substring parameter substitution ${remote%%:*}
but I am deferring it to a later day. We should replace
colon-expr with substring substitution after everybody's shell
can grok it someday, but we are not in a hurry. ]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Martin Waitz noticed that one of the case arms had an impossible
choice. It turns out that what it was checking was redundant and
the typo did not have any effect.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The command checked the presence of a ref by directly looking
into $GIT_DIR/refs directory. Update it to use show-ref.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In particular it removes duplicate information, uses short hashes (as
git-log and company) and uses .. for fast forwarding commits and ... for
not-fast-forwarding commits (shorter, easier to copy&paste). It also
reformat the output as:
1. the ones we store in our local ref (either branches or tags):
1a) fast-forward
* refs/heads/origin: fast forward to branch 'master' of ../git/
old..new: 1ad7a06..bc1a580
1b) same (only shown under -v)
* refs/heads/next: same as branch 'origin/next' of ../git/
commit: ce47b9f
1c) non-fast-forward, forced
* refs/heads/pu: forcing update to non-fast forward branch 'pu' of ../git/
old...new: 7c733a8...5faa935
1d) non-fast-forward, did not update because not forced
* refs/heads/po: not updating to non-fast forward branch 'po' of ../git/
old...new: 7c733a8...5faa935
1e) creating a new local ref to store
* refs/tags/v1.4.2-rc4: storing tag 'v1.4.2-rc4' of ../git/
tag: 8c7a107
* refs/heads/next: storing branch 'next' of ../git/
commit: f8a20ae
2. the ones we do not store in our local ref (only shown under -v):
* fetched branch 'master' of ../git
commit: 695dffe
* fetched tag 'v1.4.2-rc4' of ../git
tag: 8c7a107
Signed-off-by: Santi B.ANijar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This prevents the fetch of the heads again in the second call of fetch_main.
Signed-off-by: Santi Béjar <sbejar@gmail.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>
If in branch "foo" and this in config:
[branch "foo"]
remote=bar
"git fetch" = "git fetch bar"
"git pull" = "git pull bar"
Signed-off-by: Santi Béjar <sbejar@gmail.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>
When --keep is specified there is no reason to pass --thin to git-fetch-pack,
which are mutually exclusive. This does not hurt because fetch-pack disables
thin transfer when both are given internally, but still is confusing.
Signed-off-by: Junio C Hamano <junkio@cox.net>
After commit 55b7835e1b git-fetch --tags
exits with status 1 when no tags have been changed, which breaks calling
git-fetch from scripts.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When git-fetch updates a reference record in the associated reflog
what type of update took place and who caused it (git-fetch or
git-pull, by invoking git-fetch).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
NetBSD ash chokes on the optional open parenthesis for case arms. Inside
$(command substitution), however, bash barfs without. So adjust things
accordingly.
Originally pointed out by Dennis Stosberg.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-fetch validates that a remote ref resolves to a SHA1 prior to calling
git-http-fetch. This adds support for resolving a few levels of symrefs
to get to the SHA1.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The regexp on the right hand side of expr : operator somehow was
broken.
expr 'z+pu:refs/tags/ko-pu' : 'z\+\(.*\)'
does not strip '+'; write 'z+\(.*\)' instead.
We probably should switch to shell based substring post 1.3.0;
that's not bashism but just POSIX anyway.
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>
We can now easily fetch and merge things from heads in the
refs/remotes/ hierarchy in remote repositories.
The refs/remotes/ hierarchy is likely to become the standard for
tracking foreign SCMs, as well as the location of Pull: targets
for tracking remote branches in newly cloned repositories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Unless --no-tags flag was given, git-fetch tried to always
follow remote tags that point at the commits we picked up.
It is not very useful to pick up tags from remote unless storing
the fetched branch head in a local tracking branch. This is
especially true if the fetch is done to merge the remote branch
into our current branch as one-shot basis (i.e. "please pull"),
and is even harmful if the remote repository has many irrelevant
tags.
This proposed update disables the automated tag following unless
we are storing the a fetched branch head in a local tracking
branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Johannes noticed the recent addition of this new flag
inadvertently took over existing --update-head-ok (-u). Require
longer abbreviation to this new option which would be needed in
a rare setup.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-peek-remote needs to handle a -u|--upload-pack parameter just like
git-fetch (and git-fetch has to pass it on to git-peek-remote).
(This is actually a follow-up to my previous git-fetch patch.)
Signed-off-by: Michal Ostrowski <mostrows@heater.watson.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this, there is no way to specify a remote executable when
invoking git-pull/git-fetch as there is for git-clone.
[jc: I have a mild suspicion that this is a broken environment (aka
sysadmin disservice). It may be legal to configure your sshd to
spawn named program without involving shell at all, and if your
sysadmin does so and you have your git programs under your home
directory, you would need something like this, but then I suspect
you would need such workaround everywhere, not just git. But we
have these options we can use to work around the issue, so there
is no strong reason not to reject this patch, either. ]
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I added things to ls-remote so that Cogito can auto-follow tags
easily and correctly a while ago, but git-fetch did not use the
facility. Recently added git-describe command relies on
repository keeping up-to-date set of tags, which made it much
more attractive to automatically follow tags, so we do that as
well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the other end was prepared with older git and has tags that
do not follow the naming convention (see check-ref-format), do not
barf but simply reject to copy them.
Initial fix by Simon Richter, but done differently.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise "git pull --tags" would mistakenly try to merge all of
them, which is never what the user wants.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now all the users of this script detect its exit status and die,
complaining that it is outside git repository. So move the code
that dies from all callers to git-sh-setup script.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When doing something like
git fetch --tags origin
the excessively verbose output of git fetch makes the result totally
unreadable. It's impossible to tell if it actually fetched anything new or
not, since the screen will fill up with an endless supply of
...
* committish: 9165ec17fd
tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git
* refs/tags/v0.99.7c: same as tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git
...
and any new tags that got fetched will be totally hidden.
So add a new "--verbose" flag to "git fetch" to enable this verbose mode,
but make the default be quiet.
NOTE! The quiet mode will still report about new or changed heads, so if
you are really fetching a new head, you'll see something like this:
[torvalds@g5 git]$ git fetch --tags parent
Packing 6 objects
Unpacking 6 objects
100% (6/6) done
* refs/tags/v1.0rc2: storing tag 'v1.0rc2' of master.kernel.org:/pub/scm/git/git
* refs/tags/v1.0rc3: storing tag 'v1.0rc3' of master.kernel.org:/pub/scm/git/git
* refs/tags/v1.0rc1: storing tag 'v1.0rc1' of master.kernel.org:/pub/scm/git/git
which actually tells you something useful that isn't hidden by all the
useless crud that you already had.
Extensively tested (hey, for me, this _is_ extensive) by doing a
rm .git/refs/tags/v1.0rc*
and re-fetching with both --verbose and without.
NOTE! This means that if the fetch didn't actually fetch anything at all,
git fetch will be totally quiet. I think that's much better than being so
verbose that you can't even tell whether something was fetched or not, but
some people might prefer to get a "nothing to fetch" message in that case.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise, git-clone silently failed to clone a remote
repository where redirections (ie. a response with a
"Location" header line) are used.
This includes the fixes from Nick Hengeveld.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano