[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