On Wed, May 09, 2012 at 01:02:41PM -0700, Junio C Hamano wrote:
> SZEDER Gábor <szeder@xxxxxxxxxx> writes:
>
> > Since HEAD is a single-line file and the symbolic ref format is quite
> > simple to recognize and parse,...
>
> Strictly speaking, that is true only if you somehow know that HEAD is not
> a symlinked symref. You may end up reading [0-9a-f]{40} out of HEAD
> without learning where the symbolic link pointed at.
>
> I personally do not _know_ of anybody who is still using a symlinked
> symref, but the reasoning behind 9f0bb90 (core.prefersymlinkrefs: use
> symlinks for .git/HEAD, 2006-05-02) cannot go away by definition until
> every project that benefited from the configuration the commit introduced
> goes extinct, so I wouldn't be surprised if you get complaints from the
> users if we adopt this patch.
Symlinked symref, wow. That was long before my time ;)
So, let's see whether I understand it correctly:
- If HEAD is a symlink, then it's a symlinked symref, and points to
a real ref file somewhere under refs/.
- If HEAD is a regular file, then it's either a symref containing
'ref: refs/...', or it's a detached HEAD containing 40 hexdigits.
If the above is right, then we could check with bash builtins whether
HEAD is a symbolic link, which is cheap, and stick to '$(git
symbolic-ref HEAD)' if it is, or use bash builtins if it isn't, right?
This way we could get most of the performance benefits for modern
HEADs, while still supporting symlinked symrefs.
Gábor
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html