for-each-ref: Do not lookup objects when they will not be used
This makes commands such as `git for-each-ref --format='%(refname)'`,
which are used heavily by the bash_completion code, run about 6 times
faster on an uncached repository (3 s intead of 18 s on my linux-2.6
repository with several remotes).
Signed-off-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ar/unlink-err:
print unlink(2) errno in copy_or_link_directory
replace direct calls to unlink(2) with unlink_or_warn
Introduce an unlink(2) wrapper which gives warning if unlink failed
cat-file with an object on the command line requires an
option to tell it what to output (type, size, pretty-print,
etc). However, the square brackets in the usage imply that
those options are not required. This patch switches them to
parentheses to indicate "required but grouped-OR" (curly
braces might also work, but this follows the convention used
already by "git stash").
While we're at it, let's change the <sha1> specifier in the
usage to <object>. That's what the documentation uses, and
it does actually use the regular object lookup.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch: report ref storage DF errors more accurately
When we fail to store a fetched ref, we recommend that the
user try running "git prune" to remove up any old refs that
have been deleted by the remote, which would clear up any DF
conflicts. However, ref storage might fail for other
reasons (e.g., permissions problems) in which case the
advice is useless and misleading.
This patch detects when there is an actual DF situation and
only issues the advice when one is found.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
One of the ways that locking might fail is that there is a
DF conflict between two refs (e.g., you want to lock
"foo/bar" but "foo" already exists). In this case, we return
an error, but there is no way for the caller to know the
specific problem.
This patch sets errno to ENOTDIR, which is the most sensible
code. It's what we would see if the refs were stored purely
in the filesystem (but these days we must check the
namespace manually due to packed refs).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
As noticed by Dmitry Gryazin: When a pattern is found but it doesn't
start and end at word boundaries, bol is forwarded to after the match and
the pattern is searched again. When a pattern is finally found between
word boundaries, the match offsets are off by the number of characters
that have been skipped.
This patch corrects the offsets to be relative to the value of bol as
passed to match_one_pattern() by its caller.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
You might end up with a situation where you have tons of pack files, e.g.
when using hg2git. In this situation, all kinds of operations may
end up with a "too many files open" error. Let's recover gracefully from
that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Looks-right-to-me-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The v0.99 tag is special in that it contains no "tagger"
header.
The bug is obvious in copy_email, which carefully checks to
make sure the result of a strchr is non-NULL, but only after
already having used it to perform other work. The fix is to
move the check up.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
show-branch: Fix die message in parse_reflog_param()
Commit 76a44c5 (show-branch --reflog: show the reflog message at the
top, 2007-01-19) introduced parse_reflog_param(). The die() call was
incorrectly passed arg + 9, when it should have been passed arg.
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
dir.c: clean up handling of 'path' parameter in read_directory_recursive()
Right now we pass two different pathnames ('path' and 'base') down to
read_directory_recursive(), and the only real reason for that is that we
want to allow an empty 'base' parameter, but when we do so, we need the
pathname to "opendir()" to be "." rather than the empty string.
And rather than handle that confusion in the caller, we can just fix
read_directory_recursive() to handle the case of an empty path itself,
by just passing opendir() a "." ourselves if the path is empty.
This would allow us to then drop one of the pathnames entirely from the
calling convention, but rather than do that, we'll start separating them
out as a "filesystem pathname" (the one we use for filesystem accesses)
and a "git internal base name" (which is the name that we use for git
internally).
That will eventually allow us to do things like handle different
encodings (eg the filesystem pathnames might be Latin1, while git itself
would use UTF-8 for filename information).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In these two places we are casting part of our unsigned char sha1 array into
an unsigned int, which violates GCCs strict-aliasing rules (and probably
other compilers).
Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: simplify "current branch" in __git_ps1()
As I very often work on a detached HEAD, I found it pretty confusing
when __git_ps1() said 'some-name'. Did I create a branch with that name
by mistake, or do I happen to be on a commit with that exact tag?
This patch fixes the issue by enclosing non branch names in a pair of
parentheses when used to substitute %s token in __git_ps1() argument.
It also fixes a small bug where the branch part is left empty when
.git/HEAD is unreadable for whatever reason. The output now says
"(unknown)".
completion: fix PS1 display during a merge on detached HEAD
If your merge stops in a conflict while on a detached HEAD, recent
completion code fails to show anything. This was because various cases
added to support the operation-in-progress markers (e.g. REBASE, MERGING)
forgot that they need to set the variable "b" to something for the result
they computed to be displayed at all.
Probably not many people make trial merges on a detached HEAD (which is
tremendously useful feature of git, by the way), and that may be why this
was not noticed for a long time.
Acked-By: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-checkout: Don't tell user that HEAD has moved before it has
Previously, checkout would tell the user this message before moving HEAD,
without regard to whether the upcoming move will result in success.
If the move failed, this causes confusion.
Show the message after the move, unless the move failed.
Signed-off-by: Daniel Cordero <theappleman@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add NO_CROSS_DIRECTORY_HARDLINKS support to the Makefile
When the installed programs are tar'ed up and installed on a system where
bin/ and libexec/git-core/ live on different file systems, we do not want
libexec/git-core/git-* to be hardlinks to bin/git.
Noticed by Cedric Staniewski.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The logic in 83ae209 (checkout branch: prime cache-tree fully,
2009-04-20) is bogus; checkout can switch branches with a dirty
index and in such a case the tree won't match HEAD.
merge-recursive: never leave index unmerged while recursing
When you are trying to come up with the final result (i.e. depth=0), you
want to record how the conflict arose by registering the state of the
common ancestor, your branch and the other branch in the index, hence you
want to do update_stages().
When you are merging with positive depth, that is because of a criss-cross
merge situation. In such a case, you would need to record the tentative
result, with conflict markers and all, as if the merge went cleanly, even
if there are conflicts, in order to write it out as a tree object later to
be used as a common ancestor tree.
update_file() calls update_file_flags() with update_cache=1 to signal that
the result needs to be written to the index at stage #0 (i.e. merged), and
the code should not clobber the index further by calling update_stages().
The codepath to deal with rename/delete conflict in a recursive merge
however left the index unmerged.
Signed-off-by: Dave Olszewski <cxreg@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach 'git checkout' to preload the index contents
This makes git checkout know to use the threaded index preloading if it
is enabled in the config file. You need to have
[core]
preloadindex = true
in your config file to see it, and for that feature to make sense your
filesystem needs to be able to do concurrent 'lstat()' lookups, but when
that is the case (especially NFS over a high-latency network), this can
be a noticeable performance win.
But with a low-latency network and at least older Linux NFS clients, this
will clearly potentially cause a lot of lock contention. It may still
speed up the uncached case, but the threading and locking overhead will
result in the cached case likely slowing down.
That was almost certainly fixed by Linux commit fc0f684c2 ("NFS: Remove
BKL from NFS lookup code"), but that one got merged into 2.6.27-rc1, so
older kernel versions than 2.6.27 will not scale very well.
But regardless, it's the right thing to do. If your filesystem doesn't
scale, don't enable index preloading.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Avoid unnecessary 'lstat()' calls in 'get_stat_data()'
When we ask get_stat_data() to get the mode and size of an index entry,
we can avoid the lstat() call if we have marked the index entry as being
uptodate due to earlier lstat() calls.
This avoids a lot of unnecessary lstat() calls in eg 'git checkout',
where the last phase shows the differences to the working tree
(requiring a diff), but earlier phases have already verified the index.
On the kernel repo (with a fast machine and everything cached), this
changes timings of a nul 'git checkout' from
so it can obviously be noticeable, although equally obviously it's not a
show-stopper on this particular machine. The difference is likely larger
on slower machines, or with operating systems that don't do as good a job
of name caching.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
add: don't complain when adding empty project root
We try to warn the user if one of their pathspecs caused no
matches, as it may have been a typo. However, we disable the
warning if the pathspec points to an existing file, since
that means it is not a typo but simply an empty directory.
Unfortunately, the file_exists() test was broken for one
special case: the pathspec of the project root is just "".
This patch detects this special case and acts as if the file
exists (which it must, since it is the project root).
The user-visible effect is that this:
$ mkdir repo && cd repo && git init && git add .
used to complain like:
fatal: pathspec '' did not match any files
but now is a silent no-op.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
format-patch let -k override a config-specified format.numbered
Let a command-line --keep-subject (-k) override a config-specified
format.numbered (--numbered (-n)), rather than provoking the
"-n and -k are mutually exclusive" failure.
* t4021-format-patch-numbered.sh: Test for the above
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The alias argv comes from the split_cmdline function, which
splits the config text for the alias into an array of
strings. It returns the number of elements in the array, but
does not actually put a NULL at the end of the array.
Later, the trace function tries to print this argv and
assumes that it has the trailing NULL.
The split_cmdline function is probably at fault, since argv
lists almost always end with a NULL signal. This patch adds
one, in addition to the returned count; this doesn't hurt
the other callers at all, since they were presumably using
the count already (and will never look at the NULL).
While we're there and using ALLOC_GROW, let's clean up the
other manual grow.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t4200: convert sed expression which operates on non-text file to perl
POSIX only requires sed to work on text files and MERGE_RR is not a text
file. Some versions of sed complain that this file is not newline
terminated, and exit non-zero. Use perl instead which does not have a
problem with it.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
These two lines appear to be unnecessary. They set variables which are not
used afterwards. The primary motivation to remove them is that the sed
invocation exits non-zero for seds which require newline termination of
input files.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/annotate-tests.sh: avoid passing a non-newline terminated file to sed
Some versions of sed exit non-zero if the file they are supplied is not
newline terminated. Solaris's /usr/xpg4/bin/sed is one such sed. So
rework this test to avoid doing so.
This affects tests t8001-annotate.sh and t8002-blame.sh.
t4118: avoid sed invocation on file without terminating newline
Some versions of sed exit non-zero if the file they are supplied is not
newline terminated. Solaris's /usr/xpg4/bin/sed is one such sed. In
this case the sed invocation can be avoided entirely since the resulting
file is equivalent to a previously created file. So, just copy that file
into place instead.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-clean doc: the command only affects paths under $(cwd)
Fredrik Skolmli and Thomas Rast noticed that it was left unstated that
"git clean" ran from a subdirectory will not affect anything outside it,
with or without path limiters.
* maint:
improve error message in config.c
t4018-diff-funcname: add cpp xfuncname pattern to syntax test
Work around BSD whose typeof(tv.tv_sec) != time_t
git-am.txt: reword extra headers in message body
git-am.txt: Use date or value instead of time or timestamp
git-am.txt: add an 'a', say what 'it' is, simplify a sentence
dir.c: Fix two minor grammatical errors in comments
git-svn: fix a sloppy Getopt::Long usage
According to POSIX, tv_sec is supposed to be a time_t, but OpenBSD
(and FreeBSD, too) defines it to be a long, which triggers a type
mismatch when a pointer to it is given to localtime_r().
Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add completion for --confirm, --suppress-cc, and --smtp-encryption
command line arguments. Add completion for aliasfiletype and confirm
configuration variables.
Since --smtp-ssl is deprecated, replace it with --smtp-encryption and
the two options ssl and tls.
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Getopt-Long v2.38 is much stricter about sloppy getopt usage. The
trailing pipe causes git-svn testcases to fail for all of the --stdin
argument calls.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jc/maint-read-tree-multi' into maint
* jc/maint-read-tree-multi:
checkout branch: prime cache-tree fully
read-tree -m A B: prime cache-tree from the switched-to tree
Move prime_cache_tree() to cache-tree.c
read-tree A B: do not corrupt cache-tree
* mk/maint-apply-swap:
tests: make test-apply-criss-cross-rename more robust
builtin-apply: keep information about files to be deleted
tests: test applying criss-cross rename patch
Merge branch 'jc/maint-1.6.0-keep-pack' into maint-1.6.1
* jc/maint-1.6.0-keep-pack:
pack-objects: don't loosen objects available in alternate or kept packs
t7700: demonstrate repack flaw which may loosen objects unnecessarily
Remove --kept-pack-only option and associated infrastructure
pack-objects: only repack or loosen objects residing in "local" packs
git-repack.sh: don't use --kept-pack-only option to pack-objects
t7700-repack: add two new tests demonstrating repacking flaws
is_kept_pack(): final clean-up
Simplify is_kept_pack()
Consolidate ignore_packed logic more
has_sha1_kept_pack(): take "struct rev_info"
has_sha1_pack(): refactor "pretend these packs do not exist" interface
git-repack: resist stray environment variable
Merge branch 'bs/maint-1.6.0-tree-walk-prefix' into maint-1.6.1
* bs/maint-1.6.0-tree-walk-prefix:
match_tree_entry(): a pathspec only matches at directory boundaries
tree_entry_interesting: a pathspec only matches at directory boundary
honor repack.usedeltabaseoffset when fetching packs
If the local receiving repository has disabled the use of delta base
offset, for example to retain compatibility with older versions of
Git that predate OFS_DELTA, we shouldn't ask for ofs-delta support
when we obtain a pack from the remote server.
[ issue noticed by Shawn Pearce ]
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://repo.or.cz/git-gui:
git-gui: Fixes for Mac OS X TkAqua
git-gui: Update Russian translation
git-gui: run post-checkout hook after clone
git-gui: Ensure consistent usage of mergetool.keepBackup
git-gui: fix use of undeclared variable diff_empty_count
git-gui (Win): make starting via "Git GUI Here" on .git/ possible
git-gui (Win): make "Explore Working Copy" more robust
git-gui: run post-checkout hook on checkout
git-gui: When calling post-commit hook wrong variable was cleared.
git-gui: use `git --html-path` to get the location of installed HTML docs
git-gui: fix deleting from the context menu with empty selection
git-gui: minor spelling fix and string factorisation.
git-gui: various French translation fixes
git-gui: Fix merge conflict display error when filename contains spaces
git-gui: don't hide the Browse button when resizing the repo chooser
Append ampersand to "Target" of lnk files created by do_cygwin_shortcut
git-gui: Support more git version notations.
git-gui: Avoid an infinite rescan loop in handle_empty_diff.
git-gui: Fix post-commit status with subject in non-locale encoding
The fetching of OFS_DELTA objects has been negotiated between both peers
since git version 1.4.4. However, this was missing from the push side
where every OFS_DELTA objects were always converted to REF_DELTA objects
causing an increase in transferred data.
To fix this, both the client and the server processes have to be
modified: the former to invoke pack-objects with --delta-base-offset
when the server provides the ofs-delta capability, and the later to send
that capability when OFS_DELTA objects are allowed as already indicated
by the repack.usedeltabaseoffset config variable which is TRUE by
default since git v1.6.0.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>