From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20572 invoked by alias); 29 Mar 2010 14:04:46 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 27845 Received: (qmail 24134 invoked from network); 29 Mar 2010 14:04:43 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at benizi.com designates 64.130.10.15 as permitted sender) Date: Mon, 29 Mar 2010 09:56:43 -0400 (EDT) From: "Benjamin R. Haskell" To: zsh-workers@zsh.org Subject: Re: [PATCH] _git: Also complete FETCH_HEAD, ORIG_HEAD and MERGE_HEAD. In-Reply-To: Message-ID: References: <20100321172336.GA4151@ruderich.org> <20100322012544.GA6014@ruderich.org> User-Agent: Alpine 2.01 (LNX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463810530-1062591721-1269382009=:19615" Content-ID: ---1463810530-1062591721-1269382009=:19615 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: [oops, sat in my drafts] On Mon, 22 Mar 2010, Nikolai Weibull wrote: > On Mon, Mar 22, 2010 at 03:30, Benjamin R. Haskell wrote: > > Testing the existence of $gitdir/{refname} seems a fine compromise. > > (Really, I don't see the issue; this seems like a drop in the bucket > > of _git's performance issues...  I s'pose the forks are > > prohibitively expensive on Win32?  Revised patch below anyway.) > > > (In case it's unclear, I prefer my previous patch -- doesn't _git > > fork all over the place? -- but either one's preferable to no-change > > or always-adding-them.) > > Yes, it does, and, as you mention, it’s horribly slow to fork on > Windows. I mean, what where they thinking? But I question the value > of forking for this particular test. Still, it’s more correct to use > rev-parse. As your patch uses rev-parse to find gitdir once already, > we’re not gaining much by globbing instead. > > I just ran a benchmark on Cygwin and it takes about 0.5 seconds to run > four rev-parses. > > Perhaps completing them all without checking if they’re valid > beforehand is the best solution? I'd still rather see some checking than none at all. (MERGE_HEAD isn't often applicable, for example.) In the context I was using to test: $ git log It appears to be completing both tags and branches, and it already forks git once to find each of those (@lines 3117 and 3140). Four more forks (the version calling rev-parse on each name) might be excessive, but one doesn't seem so bad (the version calling it once to get --git-dir) for the added filtering. rev-parse each: 100% correct, only much slower on Win32 (~.5s) rev-parse dir + glob: mostly correct, a-bit-slower on Win32 (~.125s) always-complete: usually wrong, no slower Really, I feel like the forking cost would prohibit _git from being useful on Win32 in the first place, so it seems an odd metric to use. (Are there other systems where the fork is expensive? AFAIK, anything Unix-like shouldn't incur too much cost for it, which leaves Win32 and ...?) -- Best, Ben ---1463810530-1062591721-1269382009=:19615--