git grep: be careful to use mutexes only when they are initialized
Rather nasty things happen when a mutex is not initialized but locked
nevertheless. Now, when we're not running in a threaded manner, the mutex
is not initialized, which is correct. But then we went and used the mutex
anyway, which -- at least on Windows -- leads to a hard crash (ordinarily
it would be called a segmentation fault, but in Windows speak it is an
access violation).
This problem was identified by our faithful tests when run in the msysGit
environment.
To avoid having to wrap the line due to the 80 column limit, we use
the name "WHEN_THREADED" instead of "IF_USE_THREADS" because it is one
character shorter. Which is all we need in this case.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
RelNotes/1.7.7.1: setgid bit patch is about fixing "git init" via Makefile setting
The change was actually about "git init -s" which sets the setgid bit on
SysV-style systems to allow shared access to a repository, and can provoke
errors on BSD-style systems, depending on how permissive the filesystem in
use wants to be.
More to the point, the patch was just taking a fix that arrived for
FreeBSD in v1.5.5 days and making it also apply to machines using an
(obscure) GNU userland/FreeBSD kernel mixture.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/broken-ref-dwim-fix:
resolve_ref(): report breakage to the caller without warning
resolve_ref(): expose REF_ISBROKEN flag
refs.c: move dwim_ref()/dwim_log() from sha1_name.c
* mh/ref-api:
clear_ref_cache(): inline function
write_ref_sha1(): only invalidate the loose ref cache
clear_ref_cache(): extract two new functions
clear_ref_cache(): rename parameter
invalidate_ref_cache(): expose this function in the refs API
invalidate_ref_cache(): take the submodule as parameter
invalidate_ref_cache(): rename function from invalidate_cached_refs()
* jk/maint-pack-objects-compete-with-delete:
downgrade "packfile cannot be accessed" errors to warnings
pack-objects: protect against disappearing packs
* ph/transport-with-gitfile:
Fix is_gitfile() for files too small or larger than PATH_MAX to be a gitfile
Add test showing git-fetch groks gitfiles
Teach transport about the gitfile mechanism
Learn to handle gitfiles in enter_repo
enter_repo: do not modify input
This fixes a condition in filter_forks_from_projects_list that failed if
process directory was different from project root: in such case, the subroutine
was a no-op and forks were not detected.
Signed-off-by: Julien Muchembled <jm@jmuchemb.eu> Tested-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: remove broken dead code from __git_heads() and __git_tags()
__git_heads() was introduced in 5de40f5 (Teach bash about
git-repo-config., 2006-11-27), and __git_tags() in 88e21dc (Teach bash
about completing arguments for git-tag, 2007-08-31). As their name
suggests, __git_heads() is supposed to list only branches, and
__git_tags() only tags.
Since their introduction both of these functions consist of two
distinct parts. The first part gets branches or tags, respectively,
from a local repositoty using 'git for-each-ref'. The second part
queries a remote repository given as argument using 'git ls-remote'.
These remote-querying parts are broken in both functions since their
introduction, because they list both branches and tags from the remote
repository. (The 'git ls-remote' query is not limited to list only
heads or tags, respectively, and the for loop filtering the query
results prints everything except dereferenced tags.) This breakage
could be easily fixed by passing the '--heads' or '--tags' options or
appropriate refs patterns to the 'git ls-remote' invocations.
However, that no one noticed this breakage yet is probably not a
coincidence: neither of these two functions were used to query a
remote repository, the remote-querying parts were dead code already
upon thier introduction and remained dead ever since.
Since those parts of code are broken, are and were never used, stop
the bit-rotting and remove them.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: fast initial completion for config 'remote.*.fetch' value
Refspecs for branches in a remote repository start with 'refs/heads/',
so completing those refspecs with 'git config remote.origin.fetch
<TAB>' always offers 'refs/heads/' first, because that's the unique
part of the possible refspecs. But it does so only after querying the
remote with 'git ls-remote', which can take a while when the request
goes through some slower network to a remote server.
Don't waste the user's time and offer 'refs/heads/' right away for
'git config remote.origin.fetch <TAB>'.
The reason for putting 'refs/heads/' directly into COMPREPLY instead
of using __gitcomp() is to avoid __gitcomp() adding a trailing space.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: improve ls-remote output filtering in __git_refs_remotes()
This follows suit of a previous patch for __git_refs(): use a
while-read loop and let bash's word splitting get rid of object names
from 'git ls-remote's output.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: query only refs/heads/ in __git_refs_remotes()
__git_refs_remotes() is used to provide completion for refspecs to set
'remote.*.fetch' config variables for branches on the given remote.
So it's really only interested in refs under 'refs/heads/', but it
queries the remote for all its refs and then filters out all refs
outside of 'refs/heads/'.
Let 'git ls-remote' do the filtering.
Also remove the unused $cmd variable from __git_refs_remotes().
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: support full refs from remote repositories
When the __git_refs() completion helper function lists refs from a
local repository, it usually lists the refs' short name, except when
it needs to provide completion for words starting with refs, because
in that case it lists full ref names, see 608efb87 (bash: complete
full refs, 2008-11-28).
Add the same functionality to the code path dealing with remote
repositories, too.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: improve ls-remote output filtering in __git_refs()
The remote-handling part of __git_refs() has a nice for loop and state
machine case statement to iterate over all words from the output of
'git ls-remote' to identify object names and ref names. Since each
line in the output of 'git ls-remote' consists of an object name and a
ref name, we can do more effective filtering by using a while-read
loop and letting bash's word splitting take care of object names.
This way the code is easier to understand and the loop will need only
half the number of iterations than before.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: make refs completion consistent for local and remote repos
For a local repository the __git_refs() completion helper function
lists refs under 'refs/(tags|heads|remotes)/', plus some special refs
like HEAD and ORIG_HEAD. For a remote repository, however, it lists
all refs.
Fix this inconsistency by specifying refs filter patterns for 'git
ls-remote' to only list refs under 'refs/(tags|heads|remotes)/'.
For now this makes it impossible to complete refs outside of
'refs/(tags|heads|remotes)/' in a remote repository, but a followup
patch will resurrect that.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
After a unique command or option is completed, in most cases it is a
good thing to add a trailing a space, but sometimes it doesn't make
sense, e.g. when the completed word is an option taking an argument
('--option=') or a configuration section ('core.'). Therefore the
completion script uses the '-o nospace' option to prevent bash from
automatically appending a space to unique completions, and it has the
__gitcomp() function to add that trailing space only when necessary.
See 72e5e989 (bash: Add space after unique command name is completed.,
2007-02-04), 78d4d6a2 (bash: Support unique completion on git-config.,
2007-02-04), and b3391775 (bash: Support unique completion when
possible., 2007-02-04).
__gitcomp() therefore iterates over all possible completion words it
got as argument, and checks each word whether a trailing space is
necessary or not. This is ok for commands, options, etc., i.e. when
the number of words is relatively small, but can be noticeably slow
for large number of refs. However, while options might or might not
need that trailing space, refs are always handled uniformly and always
get that trailing space (or a trailing '.' for 'git config
branch.<head>.'). Since refs listed by __git_refs() & co. are
separated by newline, this allows us some optimizations with
'compgen'.
So, add a specialized variant of __gitcomp() that only deals with
possible completion words separated by a newline and uniformly appends
the trailing space to all words using 'compgen -S " "' (or any other
suffix, if specified), so no iteration over all words is needed. But
we need to fiddle with IFS, because the default IFS containing a space
would cause the added space suffix to be stripped off when compgen's
output is stored in the COMPREPLY array. Therefore we use only
newline as IFS, hence the requirement for the newline-separated
possible completion words.
Convert all callsites of __gitcomp() where it's called with refs, i.e.
when it gets the output of either __git_refs(), __git_heads(),
__git_tags(), __git_refs2(), __git_refs_remotes(), or the odd 'git
for-each-ref' somewhere in _git_config(). Also convert callsites
where it gets other uniformly handled newline separated word lists,
i.e. either remotes from __git_remotes(), names of set configuration
variables from __git_config_get_set_variables(), stashes, or commands.
Here are some timing results for dealing with 10000 refs.
Before:
$ refs="$(__git_refs ~/tmp/git/repo-with-10k-refs/)"
$ time __gitcomp "$refs"
real 0m1.134s
user 0m1.060s
sys 0m0.130s
After:
$ time __gitcomp_nl "$refs"
real 0m0.373s
user 0m0.360s
sys 0m0.020s
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: match ctags symbol names in grep patterns
A common thing to grep for is the name of a symbol. This
patch teaches the completion for "git grep" to look in
a 'tags' file, if present, to complete a pattern. For
example, in git.git:
Merge branch 'nd/maint-autofix-tag-in-head' into maint
* nd/maint-autofix-tag-in-head:
Accept tags in HEAD or MERGE_HEAD
merge: remove global variable head[]
merge: use return value of resolve_ref() to determine if HEAD is invalid
merge: keep stash[] a local variable
This allows web sites to add some specific html headers to the pages
generated by gitweb.
The new variable $site_html_head_string can be set to an html snippet that
will be inserted at the end of the <head> section of each page generated
by gitweb.
submodule::module_clone(): silence die() message from module_name()
The die() message that may occur in module_name() is not really relevant
to the user when called from module_clone(); the latter handles the
"failure" (no submodule mapping) anyway.
Analysis of other callsites is left to future work.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This brings back some of the performance lost in optimizing recency
order inside pack objects. We were doing extreme amounts of object
re-traversal: for the 2.14 million objects in the Linux kernel
repository, we were calling add_to_write_order() over 1.03 billion times
(a 0.2% hit rate, making 99.8% of of these calls extraneous).
Two optimizations take place here- we can start our objects array
iteration from a known point where we left off before we started trying
to find our tags, and we don't need to do the deep dives required by
add_family_to_write_order() if the object has already been marked as
filled.
These two optimizations bring some pretty spectacular results via `perf
stat`:
task-clock: 83373 ms --> 43800 ms (50% faster)
cycles: 221,633,461,676 --> 116,307,209,986 (47% fewer)
instructions: 149,299,179,939 --> 122,998,800,184 (18% fewer)
Helped-by: Ramsay Jones (format string fix in "die" message) Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: don't include HTTP login/password in author
On the MediaWiki side, the author information is just the MediaWiki login
of the contributor. The import turns it into login@$wiki_name to create
the author's email address on the wiki side. But we don't want this to
include the HTTP password if it's present in the URL ...
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
resolve_ref(): report breakage to the caller without warning
629cd3a (resolve_ref(): emit warnings for improperly-formatted references,
2011-09-15) made resolve_ref() warn against files that are found in the
directories the ref dwimmery looks at. The intent may be good, but these
messages come from a wrong level of the API hierarchy.
Instead record the breakage in "flags" whose purpose is to explain the
result of the function to the caller, who is in a much better position to
make intelligent decision based on the information.
This updates sha1_name.c::dwim_ref() to warn against such a broken
candidate only when it does not appear directly below $GIT_DIR to restore
the traditional behaviour, as we know many files directly underneath
$GIT_DIR/ are not refs.
Warning against "git show config --" with "$GIT_DIR/config does not look
like a well-formed ref" does not make sense, and we may later tweak the
dwimmery not to even consider them as candidates, but that is a longer
term topic.
Instead of keeping this as an internal API, let the callers find
out the reason why resolve_ref() returned NULL is not because there
was no such file in $GIT_DIR but because a file was corrupt.
* rs/pickaxe:
pickaxe: factor out pickaxe
pickaxe: give diff_grep the same signature as has_changes
pickaxe: pass diff_options to contains and has_changes
pickaxe: factor out has_changes
pickaxe: plug regex/kws leak
pickaxe: plug regex leak
pickaxe: plug diff filespec leak with empty needle
* js/no-cherry-pick-head-after-punted:
cherry-pick: do not give irrelevant advice when cherry-pick punted
revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so
* bk/submodule-in-recursive-merge:
submodule: Search for merges only at end of recursive merge
submodule: Demonstrate known breakage during recursive merge
t1300: attempting to remove a non-existent .git/config is not an error
Since some tests before test number 79 ("quoting") are skipped, .git/config
does not exist and 'rm .git/config' fails. Fix this particular case.
While at it, move other instance of 'rm .git/config' that occur in this
file inside the test function to document that the test cases want to
protect themselves from remnants of earlier tests.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-gui: set suitable extended window manager hints.
This patch uses recent Tk attributes support to specify the intended use of new
toplevels by setting the correct EWMH hint. This helps modern window managers
to apply sensible decoration for the tooltip and dialogs.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
* jn/gitweb-manpages:
gitweb: Add gitweb manpages to 'gitweb' package in git.spec
Documentation: Add gitweb config variables to git-config(1)
Documentation: Link to gitweb(1) and gitweb.conf(5) in other manpages
gitweb: Add gitweb(1) manpage for gitweb itself
gitweb: Add gitweb.conf(5) manpage for gitweb configuration files
* pt/mingw-misc-fixes:
t9901: fix line-ending dependency on windows
mingw: ensure sockets are initialized before calling gethostname
mergetools: use the correct tool for Beyond Compare 3 on Windows
t9300: do not run --cat-blob-fd related tests on MinGW
git-svn: On MSYS, escape and quote SVN_SSH also if set by the user
t9001: do not fail only due to CR/LF issues
t1020: disable the pwd test on MinGW
strbuf.c: remove unnecessary strbuf_grow() from strbuf_getwholeline()
This use of strbuf_grow() is a historical artifact that was once used to
ensure that strbuf.buf was allocated and properly nul-terminated. This
was added before the introduction of the slopbuf in b315c5c0, which
guarantees that strbuf.buf always points to a usable nul-terminated string.
So let's remove it.
Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile: ask "ls-files" to list source files if available
The [ce]tags and cscope targets used to run "find" looking for any paths
that match '*.[chS]' to feed the list of source files to downstream xargs.
Use "git ls-files" if it is already available to us, and otherwise use a
tighter "find" expression that does not list directories and does not go
into our .git directory.
Setting config gui.search.smartcase to true, the search mode in the
searchbar (from the blame view) is by default case-insensitive. But
entering an upper case letter into the search field activates the case-
sensitive search mode.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
When staging a selection of files using Shift-Click to choose a range
of files then using Ctrl-T or the Stage To Commit menu item will stage
all the selected files. However if a non-sequential range is selected
using Ctrl-Click then all but the first name selected gets staged. This
commit fixes this to properly stage all selected files by explicitly
adding the path to the list before showing the diff.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
pack-objects: use unsigned int for counter and offset values
This is done in some of the new pack layout code introduced in commit 1b4bb16b9ec331c. This more closely matches the nr_objects global that is
unsigned that these variables are based off of and bounded by.
Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function is a whole 26 bytes when compiled on x86_64, but is
currently invoked over 1.037 billion times when running pack-objects on
the Linux kernel git repository. This is hitting the point where
micro-optimizations do make a difference, and inlining it only increases
the object file size by 38 bytes.
As reported by perf, this dropped task-clock from 84183 to 83373 ms, and
total cycles from 223.5 billion to 221.6 billion. Not astronomical, but
worth getting for adding one word.
Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>