Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: git completion horribly slow in kernel tree
- X-seq: zsh-workers 24456
- From: "Mikael Magnusson" <mikachu@xxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: git completion horribly slow in kernel tree
- Date: Thu, 24 Jan 2008 07:46:12 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=B0SdMIXYGAHMLRETHEqWzyjOCDRRVDLC4leOx866FcE=; b=kCvIYZVa6jhzAKIWu+XfaFnZEO1YDcVbfotTLGYMmZWh3cH3Jzed77o4vyOD1p3THbi2eL0tWV+47ECq2xFyAl6gQg1NZzaqoTYetg6W6zU/vghA6UBrU9xgK1KjyCvtyW1pF3LBGlsc/343jpLEf7Xp/U7l6ldoNhgq/24i3V4=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=svkFNTNZ05nxE2DdrrMrzNc4PfV+NCNZAvrxHHuccDGwp5hQc3VB7JijpsuKP94X8NAHQ3zhWaZqc6g2z/Cu2/ttpJvahJCzRnxYn8jXGVOuQGRDkLJ5ofLMRxBDimJQPDGZxoPk/4LRk8DfYUBug/SmoRn6WXI3Txlk2OnlPGw=
- In-reply-to: <20080123164835.GA32341@xxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <slrnfongql.jes.joerg@xxxxxxxxxxxx> <237967ef0801141339p73414915xc411253211ed7467@xxxxxxxxxxxxxx> <20080122011932.GB16813@xxxxxxxxxxx> <237967ef0801211740s1ee07850vc25984a7af262cac@xxxxxxxxxxxxxx> <20080122162222.GA503@xxxxxxxxxxx> <20080122171249.GA2361@xxxxxxxxxxx> <237967ef0801230320n7fbd3582xf8a149e10f83e708@xxxxxxxxxxxxxx> <20080123132925.GA26303@xxxxxxxxxxx> <237967ef0801230830t55434367p31c78b56df461454@xxxxxxxxxxxxxx> <20080123164835.GA32341@xxxxxxxxxxx>
On 23/01/2008, Clint Adams <clint@xxxxxxx> wrote:
> On Wed, Jan 23, 2008 at 05:30:05PM +0100, Mikael Magnusson wrote:
> > Hm, I don't really know... git ls-tree seems to not want to output ..,
> > if you specify --full-name, it does show the dir you specify, but
> > relative to the root of the project. So if you're in proj/dir1/dir2
> > and git ls-tree --full-name --name-only HEAD .., you will get files
> > shown as dir1/file1. I guess it's possible to use that output, but
> > maybe it's easier to just manually cd to the proj/ dir first :). I
> > just looked at the bash completer (which is very confusing code), and
> > it seems to use something like
> > git --git-dir=$(git rev-parse --git-dir) ls-tree $ref:prefix
> > which lists the file as file1 instead of dir1/file1. (no idea why it
> > doesn't use --name-only).
>
> I just looked and git-add completion is using ls-files, which can't
> handle relative paths either.
Hm, this "works", but it definitely isn't nice, and doesn't work when
you type the shorter path manually first.
# Untracked files:
# Src/Modules/curses_keys.h
if i'm sitting in Src/Builtins, the following code will produce
git add <tab>
git add ../<tab>
git add ../../<tab>
git add ../../Src/Modules<tab>
git add ../../Src/Modules/curses_keys.h
which is not so great.
Annoyingly, when i'm sitting in Src/Builtins, git status produces the following
# Untracked files:
# ../Modules/curses_keys.h
I don't know how often one really wants to git add files above the
current dir, but it just annoys me that it's so hard to fix. :)
(( $+functions[__git_files] )) ||
__git_files () {
local expl files ls_opts opts gitdir cdup
zparseopts -D -E -a opts -- -cached -deleted -modified -others
-ignored -unmerged -killed
gitdir=$(_call_program gitdir git rev-parse --git-dir 2>/dev/null)
__git_command_successful || return
ls_opts=("--exclude-per-directory=.gitignore")
[[ -f "$gitdir/info/exclude" ]] &&
ls_opts+="--exclude-from=$gitdir/info/exclude"
cdup=$(_call_program revparse git rev-parse --show-cdup)
files=(${(ps:\0:)"$(_call_program files git ls-files --full-name -z
$ls_opts $opts $cdup 2>/dev/null)"})
files=$cdup${^files}
__git_command_successful || return
_wanted files expl 'index file' _multi_parts $@ - / files
}
--
Mikael Magnusson
Messages sorted by:
Reverse Date,
Date,
Thread,
Author