Makefile: make mandir, htmldir and infodir absolute

This matches the use of the variables with the same names in autotools,
reducing the potential for user surprise.

Using relative paths in these variables also causes issues if they are
exported from the Makefile, as discussed in commit c09d62f (Makefile: do
not export mandir/htmldir/infodir, 2013-02-12).

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
name-hash.c: fix endless loop with core.ignorecase=true

With core.ignorecase=true, name-hash.c builds a case insensitive index of
all tracked directories. Currently, the existing cache entry structures are
added multiple times to the same hashtable (with different name lengths and
hash codes). However, there's only one dir_next pointer, which gets
completely messed up in case of hash collisions. In the worst case, this
causes an endless loop if ce == ce->dir_next (see t7062).

Use a separate hashtable and separate structures for the directory index
so that each directory entry has its own next pointer. Use reference
counting to track which directory entry contains files.

There are only slight changes to the name-hash.c API:
- new free_name_hash() used by read_cache.c::discard_index()
- remove_name_hash() takes an additional index_state parameter
- index_name_exists() for a directory (trailing '/') may return a cache
  entry that has been removed (CE_UNHASHED). This is not a problem as the
  return value is only used to check if the directory exists (dir.c) or to
  normalize casing of directory names (read-cache.c).

Getting rid of cache_entry.dir_next reduces memory consumption, especially
with core.ignorecase=false (which doesn't use that member at all).

With core.ignorecase=true, building the directory index is slightly faster
as we add / check the parent directory first (instead of going through all
directory levels for each file in the index). E.g. with WebKit (~200k
files, ~7k dirs), time spent in lazy_init_name_hash is reduced from 176ms
to 130ms.

Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
describe: --match=<pattern> must limit the refs even when used with --all

The logic to limit the refs used for describing with a matching pattern
with --match=<pattern> parameter was implemented incorrectly when --all
is in effect.  It just demoted a ref that did not match the pattern to
lower priority---if there aren't other refs with higher priority
that describe the given commit, such an unmatching ref was still used.

When --match is used, reject refs that do not match the given
criteria, so that with or without --all, the output will only use
refs that match the pattern.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule: add 'deinit' command

With "git submodule init" the user is able to tell git he cares about one
or more submodules and wants to have it populated on the next call to "git
submodule update". But currently there is no easy way he could tell git he
does not care about a submodule anymore and wants to get rid of his local
work tree (except he knows a lot about submodule internals and removes the
"submodule.$name.url" setting from .git/config together with the work tree
himself).

Help those users by providing a 'deinit' command. This removes the
whole submodule.<name> section from .git/config (either for the given
submodule(s) or for all those which have been initialized if '.' is used)
together with their work tree. Fail if the current work tree contains
modifications (unless forced), but don't complain when either the work
tree is already removed or no settings are found in .git/config.

Add tests and link the man pages of "git submodule deinit" and "git rm"
to assist the user in deciding whether removing or unregistering the
submodule is the right thing to do for him. Also add the deinit subcommand
to the completion list.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-completion.zsh: define __gitcomp_file compatibility function

Commit fea16b47b60 (Fri Jan 11 19:48:43 2013, Manlio Perillo,
git-completion.bash: add support for path completion), introduced a new
__gitcomp_file function that uses the bash builtin "compgen". The
function was redefined for ZSH in the deprecated section of
git-completion.bash, but not in the new git-completion.zsh script.

As a result, users of git-completion.zsh trying to complete "git add
fo<tab>" get an error:

git add fo__gitcomp_file:8: command not found: compgen

This patch adds the redefinition and removes the error.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix `make install` when configured with autoconf

Commit d8cf908c (config.mak.in: remove unused definitions) removed

    exec_prefix = @exec_prefix@

from config.mak.in, because nobody directly used ${exec_prefix}, but
overlooked that other autoconf definitions could indirectly expand that
variable.

For example the following snippet from config.mak.in

    prefix = @prefix@
    bindir = @bindir@
    gitexecdir = @libexecdir@/git-core
    datarootdir = @datarootdir@
    template_dir = @datadir@/git-core/templates
    sysconfdir = @sysconfdir@

is expanded to

    prefix = /home/kirr/local/git
    bindir = ${exec_prefix}/bin                             <-- HERE
    gitexecdir = ${exec_prefix}/libexec/git-core            <--
    datarootdir = ${prefix}/share
    template_dir = ${datarootdir}/git-core/templates
    sysconfdir = ${prefix}/etc

on my system, after `configure --prefix=$HOME/local/git`

and withot exec_prefix being defined there I get an error on
install:

    install -d -m 755 '/bin'
    install -d -m 755 '/libexec/git-core'
    install: cannot create directory `/libexec': Permission denied
    Makefile:2292: recipe for target `install' failed

Fix it.

Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jc/remove-export-from-config-mak-in' into next

* jc/remove-export-from-config-mak-in:
  Fix `make install` when configured with autoconf
Merge branch 'mp/complete-paths' into next

* mp/complete-paths:
  git-completion.zsh: define __gitcomp_file compatibility function
Merge branch 'jk/common-make-variables-export-safety' into next

Make the three variables safer to be exported to submakes by
ensuring that they are full paths so that they can be used as
installation location.

* jk/common-make-variables-export-safety:
  Makefile: make mandir, htmldir and infodir absolute
Merge branch 'jc/describe' into next

The "--match=<pattern>" option of "git describe", when used with
"--all" to allow refs that are not annotated tags to be used as a
base of description, did not restrict the output from the command
to those that match the given pattern.

We may want to have a looser matching that does not restrict to tags,
but that can be done as a follow-up topic; this step is purely a bugfix.

* jc/describe:
  describe: --match=<pattern> must limit the refs even when used with --all
Merge branch 'kb/name-hash' into next

The code to keep track of what directory names are known to Git on
platforms with case insensitive filesystems can get confused upon
a hash collision between these pathnames and looped forever.

* kb/name-hash:
  name-hash.c: fix endless loop with core.ignorecase=true
Merge branch 'jl/submodule-deinit' into next

There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init".  "submodule deinit" is the way to do so.

* jl/submodule-deinit:
  submodule: add 'deinit' command