Fix broken bash completion of local refs.
authorShawn O. Pearce <spearce@spearce.org>
Tue, 28 Nov 2006 17:12:26 +0000 (12:12 -0500)
committerJunio C Hamano <junkio@cox.net>
Tue, 28 Nov 2006 23:48:55 +0000 (15:48 -0800)
commit67ffa1142585742601011440a17528ef841bbf44
treed4f261c4fc802e74feb237f814dae77932895cfa
parent4548e855e4600a0f76329cf4f0dd9e8d17d66b08
Fix broken bash completion of local refs.

Commit 35e65ecc broke completion of local refs, e.g. "git pull . fo<tab>"
no longer would complete to "foo".  Instead it printed out an internal
git error ("fatal: Not a git repository: '.'").

The break occurred when I tried to improve performance by switching from
git-peek-remote to git-for-each-ref.  Apparently git-peek-remote will
drop into directory "$1/.git" (where $1 is its first parameter) if it
is given a repository with a working directory.  This allowed the bash
completion code to work properly even though it was not handing over
the true repository directory.

So now we do a stat in bash to see if we need to add "/.git" to the
path string before running any command with --git-dir.

I also tried to optimize away two "git rev-parse --git-dir" invocations
in common cases like "git log fo<tab>" as typically the user is in the
top level directory of their project and therefore the .git subdirectory
is in the current working directory.  This should make a difference on
systems where fork+exec might take a little while.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/completion/git-completion.bash