If everything is up-to-date locally, we don't need to even ask for a
pack-file from the remote, or try to unpack it.
This is especially important for tags - since the pack-file common commit
logic is based purely on the commit history, it will never be able to find
a common tag, and will thus always end up re-fetching them.
Especially notably, if the tag points to a non-commit (eg a tagged tree),
the pack-file would be unnecessarily big, just because it cannot any most
recent common point between commits for pruning.
Short-circuiting the case where we already have that reference means that
we avoid a lot of these in the common case.
NOTE! This only matches remote ref names against the same local name,
which works well for tags, but is not as generic as it could be. If we
ever need to, we could match against _any_ local ref (if we have it, we
have it), but this "match against same name" is simpler and more
efficient, and covers the common case.
Renaming of refs is common for branch heads, but since those are always
commits, the pack-file generation can optimize that case.
In some cases we might still end up fetching pack-files unnecessarily, but
this at least avoids the re-fetching of tags over and over if you use a
regular
git fetch --tags ...
which was the main reason behind the change.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Linus Torvalds:
make checkout-index '-a' flag saner.
Junio C Hamano:
whatchanged: document -m option from git-diff-tree.
Functions to quote and unquote pathnames in C-style.
Update git-apply to use C-style quoting for funny pathnames.
Do not quote SP.
git-checkout-index: documentation updates.
Follow the "encode minimally" principle -- our tools, including
git-apply and git-status, can handle pathnames with embedded SP just
fine. The only problematic ones are TAB and LF, and we need to quote
the metacharacters introduced for quoting.
Functions to quote and unquote pathnames in C-style.
Following the list discussion, define two functions, quote_c_style and
unquote_c_style, to help adopting the proposed way for quoting funny
pathname letters for GNU patch. The rule is described in:
Currently we do not support the leading '!', but we probably should
barf upon seeing it. Rule B4. is interpreted to require always 3
octal digits in \XYZ notation.
whatchanged: document -m option from git-diff-tree.
The documentation for git-whatchanged is meant to describe only
the most frequently used options from git-diff-tree. Because "why
doesn't it show merges" was asked more than once, we'd better
describe '-m' option there.
Johannes Schindelin:
Teach git-status about spaces in file names also on MacOSX
t5400-send-pack relies on a working cpio
Jonas Fonseca:
git.sh: quote all paths
Junio C Hamano:
Also force LC_ALL in test scripts.
OpenBSD needs the strcasestr replacement.
git-check-ref-format: reject funny ref names.
Refuse to create funny refs in clone-pack, git-fetch and receive-pack.
Ignore funny refname sent from remote
Introduce notation "ref^{type}".
Martin Langhoff:
cvsimport: don't pass --cvs-direct if user options contradict us
Ralf Baechle:
rsh.c: typo fix
Note that "funny ref" bits are not strictly fixes but rather
backport from the "master" branch. They will prevent refs and
heads with funny names from being created. In addition, what is
in the master branch will start feeding the clients unwrapped
tag information to help Martin's findtags and possibly later
Cogito. These backported "funny ref" changes are to prevent
clients on the "maint" branch from getting confused when talking
with newer git-upload-pack and when reading from info/refs file
prepared with newer git-update-server-info.
Existing "tagname^0" notation means "dereference tag zero or more
times until you cannot dereference it anymore, and make sure it is a
commit -- otherwise barf". But tags do not necessarily reference
commit objects.
This commit introduces a bit more generalized notation, "ref^{type}".
Existing "ref^0" is a shorthand for "ref^{commit}". If the type
is empty, it just dereferences tags until it hits a non-tag object.
With this, "git-rev-parse --verify 'junio-gpg-pub^{}'" shows the blob
object name -- there is no need to manually read the tag object and
find out the object name anymore.
"git-rev-parse --verify 'HEAD^{tree}'" can be used to find out the
tree object name of the HEAD commit.
This allows the remote side (most notably, upload-pack) to show
additional information without affecting the downloader. Peek-remote
does not ignore them -- this is to make it useful for Pasky's
automatic tag following.
Refuse to create funny refs in clone-pack, git-fetch and receive-pack.
Using git-check-ref-format, make sure we do not create refs with
funny names when cloning from elsewhere (clone-pack), fast forwarding
local heads (git-fetch), or somebody pushes into us (receive-pack).
Update check_ref_format() function to reject ref names that:
* has a path component that begins with a ".", or
* has a double dots "..", or
* has ASCII control character, "~", "^", ":" or SP, anywhere, or
* ends with a "/".
Use it in 'git-checkout -b', 'git-branch', and 'git-tag' to make sure
that newly created refs are well-formed.
Lacking reliable symlinks, the instructions in the tutorial did not work
in a cygwin setup. Also, a few outputs were not correct.
This patch fixes these, and adds a test case which follows the
instructions of the tutorial (except git-clone, -fetch and -push, which I
have not done yet).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
[PATCH] cvsimport: don't pass --cvs-direct if user options contradict us
Detecting if the user passed --no-cvs-direct and don't force the mode.
It allows us to support all the protocol that the standard cvs client
supports at the snail speed you should expect.
This only affects the rlog reading stage.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
It currently exits printing "git-cat-file SHA1: bad file", while
instead we must just abort the verification for light-weight
tags (e.g. referring to commit objects).
[jc: tag objects can tag anything not just commits, so I fixed
up the original patch slightly. you should be able to validate
a signed tag that points at a blob object. ]
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Junio C Hamano <junkio@cox.net>
Make sure 'make install' does not have to rebuild templates.
The dependency rule in templates directory forced 'make install'
that immediately followed 'make all' to rebuild boilerplates.
This was problematic for a workflow that built first as yourself
and then installed as root, from a working tree that is on an
NFS mounted filesystem that is unwritable by root.
git-status truncates filenames up to the first occurrence of a whitespace
character when displaying. More precisely, it displays the filename up to any
field seperator defined in $IFS.
This patch fixes a bug in git-ls-tree in which the wrong filenames are
listed if the exact same file and directory contents are present in
another location in the tree.
Added a new series of test cases for directory and filename handling.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
upload-pack: Do not choke on too many heads request.
Cloning from a repository with more than 256 refs (heads and tags
included) will choke, because upload-pack has a built-in limit of
feeding not more than MAX_NEEDS (currently 256) heads to underlying
git-rev-list. This is a problem when cloning a repository with many
tags, like http://www.linux-mips.org/pub/scm/linux.git, which has 290+
tags.
This commit introduces a new flag, --all, to git-rev-list, to include
all refs in the repository. Updated upload-pack detects requests that
ask more than MAX_NEEDS refs, and sends everything back instead.
We may probably want to tweak the definitions of MAX_NEEDS and
MAX_HAS, but that is a separate topic.
When we updated the marker for new files from 'N' to 'A', we forgot to
notice that the letter is already taken by the All-Or-None mark.
Change the All-Or-None marker to '*' to resolve this conflict.
git-diff-tree -r --diff-filter='R*' -M
shows all the changes (not just renames) that are contained in commits
that have renames, in comparison with:
git-diff-tree -r --diff-filter='R' -M
shows the same set of changes but the diff output are limited only to
renaming changes.
There was a leftover use of sed that attempted to remove the commit ID
output from git-diff-tree, which turned into an expensive no-op when
git-diff-tree output header format changed about three months ago.
Drop it.
Error message from get_sha1() on ambiguous short SHA1.
Unlike cases where "no such object exists", the case where specified
prefix is ambiguous would confuse the user if we say "no such commit"
or such. Give an extra error message from the uniqueness check if
there are more than one objects that match the given prefix.
[PATCH] Enable and fix support for base less merges.
Let the merge strategies handle the base less case if they are able to
do it. It also fixes git-resolve.sh to die if no common ancestors
exists, instead of doing the wrong thing. Furthermore, it contains a
small independent fix for git-merge.sh and a fix for a base less code
path in gitMergeCommon.py.
With this it's possible to use
git merge -s recursive 'merge message' A B
to do a base less merge of A and B.
[jc: Thanks Fredrik for fixing the brown-paper-bag in git-merge.
I fixed a small typo in git-merge-resolve fix; 'test' equality
check is spelled with single equal sign -- C-style double equal
sign is bashism.]
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
Make sure get_sha1 does not accept ambiguous sha1 prefix.
The original code did not even check alternates, and was confused if
an unpacked object was uniquely found when there was another object
that shares the same prefix in the pack.
GIT already did everything I wanted it to do since mid 0.99.7,
and it has almost everything I want it to have now, except a
couple of minor tweaks and enhancements.
The documentation for git-clone is behind the actual command.
I have been getting tired of reading the shell script to see
what the arguments are so here is an update of the actual documentation.
Signed-off-by: Eric Biederman <ebiederman@xmission.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
[PATCH] Teach the recursive merge strategy about renames.
It will now merge cases where a file was renamed in one branch and
modified in the other branch cleanly. We also detect a couple of
conflict cases now that wasn't detected before.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "git-update-index" avoid the new index file write if it didn't
make any changes to the index.
It still doesn't make things like "git status" be read-only operations in
general, but if the index file doesn't need refreshing, it now will at
least avoid making unnecessary changes.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of "git status" ignoring (and hiding) potential errors from the
"git-update-index" call, make it exit if it fails, and show the error.
In order to do this, use the "-q" flag (to ignore not-up-to-date files)
and add a new "--unmerged" flag that allows unmerged entries in the index
without any errors.
This also avoids marking the index "changed" if an entry isn't actually
modified, and makes sure that we exit with an understandable error message
if the index is corrupt or unreadable. "read_cache()" no longer returns an
error for the caller to check.
Finally, make die() and usage() exit with recognizable error codes, if we
ever want to check the failure reason in scripts.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
- The location of openssl development files got customizable.
- The location of iconv development files got customizable.
- Pass $TAR down to t5000 test so that the user can override with
'gmake TAR=gtar'.
- Solaris 'bc' does not seem to grok "define abs()". There is no
reason to use bc there -- expr would do.
This adds the counterpart of git-update-ref that lets you read
and create "symbolic refs". By default it uses a symbolic link
to represent ".git/HEAD -> refs/heads/master", but it can be compiled
to use the textfile symbolic ref.
The places that did 'readlink .git/HEAD' and 'ln -s refs/heads/blah
.git/HEAD' have been converted to use new git-symbolic-ref command, so
that they can deal with either implementation.
[PATCH] Allow reading "symbolic refs" that point to other refs
This extends the ref reading to understand a "symbolic ref": a ref file
that starts with "ref: " and points to another ref file, and thus
introduces the notion of ref aliases.
This is in preparation of allowing HEAD to eventually not be a symlink,
but one of these symbolic refs instead.
[jc: Linus originally required the prefix to be "ref: " five bytes
and nothing else, but I changed it to allow and strip any number of
leading whitespaces to match what update-ref.c does.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Teach update-ref about a symbolic ref stored in a textfile.
A symbolic ref is a regular file whose contents is "ref:", followed by
optional leading whitespaces, followed by a GIT_DIR relative pathname,
followed by optional trailing whitespaces (the optional whitespaces
are unconditionally removed, so you cannot have leading nor trailing
whitespaces). This can be used in place of a traditional symbolic
link .git/HEAD that usually points at "refs/heads/master". You can
instead have a regular file .git/HEAD whose contents is
"ref: refs/heads/master".
[jc: currently the code does not enforce the symbolic ref to begin with
refs/, unlike the symbolic link case. It may be worthwhile to require
either case to begin with refs/ and not have any /./ nor /../ in them.]
[jc: The original by Linus fetched and overwrote branch heads with
--all, which felt dangerous and wrong, so I removed it. Also this
version does not use any refs that resulted as --tags for later
merge. ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Add the sanity checks discussed on the list with Nick Hengeveld in
<20050927000931.GA15615@reactrix.com>.
* unlink of previous and rename from temp to previous can fail for
reasons other than benign ones (missing previous and missing temp).
Report these failures when we encounter them, to make diagnosing
problems easier.
* when rewinding the partially written result, make sure to
truncate the file.
Also verify the pack after downloading by calling
verify_packfile().
The archive generated with git-tar-tree had 0755 and 0644 mode bits.
This inconvenienced the extractor with umask 002 by robbing g+w bit
unconditionally. Just write it out with loose permissions bits and
let the umask of the extractor do its job.
A patch that contains no actual diff, and that doesn't change any
meta-data is bad. It shouldn't be a patch at all, and git-apply shouldn't
just accept it.
This caused a corrupted patch to be silently applied as an empty change in
the kernel, because the corruption ended up making the patch look empty.
An example of such a patch is one that contains the patch header, but
where the initial fragment header (the "@@ -nr,.." line) is missing,
causing us to not parse any fragments.
The real "patch" program will also flag such patches as bad, with the
message
patch: **** Only garbage was found in the patch input.
and we should do likewise.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
After seeing Jeff's guide, I changed my mind about the
big-rename transition plan. Even if Porcelains are kept up to
date, those web documents that describes older world order would
live longer and people will stumble across them via google
searches. And who knows how many mirrored copies there are.
The backward compatible symbolic links *will* be removed before
1.0. But that will not happen in 0.99.8.
This again makes git-pull to use git-merge, so that different merge
strategy can be specified from the command line. Without explicit
strategy parameter, it defaults to git-merge-resolve if only one
remote is pulled, and git-merge-octopus otherwise, to keep the
default behaviour of the command the same as the original.
Also this brings another usability measure: -n flag from the command
line, if given, is passed to git-merge to prevent it from running the
diffstat at the end of the merge.
This uses the git-update-ref command in scripts for safer updates.
Also places where we used to read HEAD ref by using "cat" were fixed
to use git-rev-parse. This will matter when we start using symbolic
references.
[PATCH] Support for more CURL SSL settings via environment variables
Added support for additional CURL SSL settings via environment variables.
Client certificate/key files can be specified as well as alternate CA
information.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>