Re: [PATCH] _git: Also complete FETCH_HEAD, ORIG_HEAD and MERGE_HEAD.

["Benjamin R. Haskell" <zsh@benizi.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2101 bytes --]

[oops, sat in my drafts]

On Mon, 22 Mar 2010, Nikolai Weibull wrote:

> On Mon, Mar 22, 2010 at 03:30, Benjamin R. Haskell <zsh@benizi.com> 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 <Tab>

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