Re: [PATCH] Disable USE_SYMLINK_HEAD by default

Junio C Hamano [off-list ref] writes:

Pavel Roskin [off-list ref] writes:

quoted

In particular, StGIT still needs fixing.

quoted

...

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

That's a real concern, I should agree.

I think I need to qualify this comment.  It is a real concern
because we need to know when it is safe to start using textual
symrefs everywhere, *if* we would want to do that switch.

I wonder how ready StGIT and Cogito are, but also I wonder how
ready other things are.  People built homebrew scripts around
git without calling them Porcelains, and git is designed to be
used that way.  We do not know how many things we are breaking
if we switch to do textual symrefs by default.

I just checked the latest gitweb, and it does not seem to be
ready.  I do not, however, necessarily think it is a high
priority problem.  It does not feel to me a realistic issue that
you cannot serve a public repository on a filesystem incapable
of symlinks via getweb.  This change is breaking things for
gitweb running on kernel.org machines without real benefit.

Thinking about it a bit more, the current setup to use symlinks
on systems that supports them, and textual symrefs on others, is
looking more and more sensible to me.  If supporting
symlink-challenged filesystems become a real issue for a "third
party tool", certainly that will be updated, because people
would want it.  Switching to do textual symrefs by default
everywhere is a way to *force* people to scramble and update
their scripts everywhere, but I am not so sure that is worth it;
I cannot justify why I'd be forcing them to do so, especially if
supporting VFAT is a low priority for some of the tools.

"Bit rot" may first seem a concern, but actually it is not.  I
suspect that serverish applications such as gitweb view
supporting symlink-challenged filesystems as a lower priority
task, while more client-oriented applications rate it higher.
The core support for textual symrefs cannot afford to rot as
long as some Porcelain needs it, and worrying about it would not
be a good justification to break everybody "just to see what
breaks".  On the other hand, if the support for textual symrefs
rot, it probably deserves to --- the only reason that would
happen would be because nobody uses them.

IOW, if we see real breakage in either git itself or Porcelains
that use git, send in fixes to appropriate parties.  I think
that's being constructive.  Otherwise, let's not break things
just for the sake of consistency.  I do not think that is
helping anything.