Re: [PATCH] Disable USE_SYMLINK_HEAD by default

From: Pavel Roskin <proski@gnu.org>
Date: Nov 15, 2005, 08:13 UTC
Message-ID: <1132042427.3512.50.camel@dv>
In-Reply-To: <7vveyuqto5.fsf@assigned-by-dhcp.cox.net>

On Mon, 2005-11-14 at 23:03 -0800, Junio C Hamano wrote:

Show 8 quoted lines

> 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.

Show 11 quoted lines

> > 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.

Show 6 quoted lines

> 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