Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Pavel Roskin <proski@gnu.org>]

On Mon, 2005-11-14 at 23:03 -0800, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
> 
> > Applying this patch before 1.0 may be controversial,...
> 
> If I am not mistaken, I thought the last thread on the list
> showed general consensus that symlinks were preferred when
> available.  So applying this patch anytime would be
> controversial...

I must have missed that.  If you mean "Re: Getting rid of symlinks
in .git?", I don't see any such consensus there.  The discussion drifts
to insignificant details, and I see arguments like "I couldn't care
less" and speculations about speed without any hard data at hand.

> > but I think there is a very good reason for that.
> 
> Which is...?  I do not think this paragraph justifies it:
> 
> > There should be exactly one git 1.0 repository format.  Now we
> > have two that are present in the sources and that have
> > received testing from the git users.
> 
> The one format is that .git/HEAD can either be a symlink or
> regular file text symref; both variants are tested -- wouldn't
> that be good enough?

No.  Even if git itself is tested, other tools are not.  What's worse,
the developers of those tools don't even know they are supposed to test
for two HEAD formats unless they track git changes and mailing lists
very carefully.

In particular, StGIT still needs fixing.

> The only thing I can think of that might be inconvenient is if
> you try doing "cp -a" off of a filesystem that supports symlinks
> to another filesystem that does not -- probably that would fail
> copying the symlinked .git/HEAD.  But if that is the problem,
> you could always git-clone, which should do the right thing, I
> think.

I'm talking from my experience now.  If there is an option, there are
users that have it enabled and those who have it disabled (by
definition).  As is often happens, one of the configurations is more
popular with developers.  The other configuration almost inevitably
starts suffering from the "bit rot".

It could have been prevented if the format choice was encapsulated by
git prior to its introduction.  But git-symbolic-ref didn't exist before
symrefs were implemented.  Old code outside git accesses .git/HEAD
manually.  Fixing git alone is not enough if git files are accessed
without git.

Extra complexity of any format discourages third party applications or
makes them more complex and less safe to use.

I can understand if the complexity has a balance of requirements issue
behind it.  For example, coexistence of packed and unpacked files comes
from the conflicting requirements to handle files quickly and not to
consume too much hard disk space and bandwidth.

But there is no strong (compared to portability) reason to have
symlinks, except maybe backward compatibility.  It's a weak argument
before 1.0 release.  Let's not wait until it becomes stronger.

-- 
Regards,
Pavel Roskin