Pavel Roskin [off-list ref] 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...
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?
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.
On Mon, 2005-11-14 at 23:03 -0800, Junio C Hamano wrote:
Pavel Roskin [off-list ref] writes:
quoted
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.
quoted
but I think there is a very good reason for that.
Which is...? I do not think this paragraph justifies it:
quoted
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