patchDisable USE_SYMLINK_HEAD by default

Disable USE_SYMLINK_HEAD by default. Recommend using it only for compatibility with older software.

Treat USE_SYMLINK_HEAD like other optional defines - check whether it's defined, not its value.

Signed-off-by: Pavel Roskin <proski@gnu.org>

--- Applying this patch before 1.0 may be controversial, but I think there is a very good reason for that. 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.

Of those two formats, I prefer the one that is platform independent and not very demanding with regard to filesystems and transfer protocols. That format should be good enough so that we don't plan to change it as soon as version 1.0 is released. Any third party software claiming to support git 1.0 should need to support one repository format.

Pavel Roskin <proski@gnu.org> writes:

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

Which is...?  I do not think this paragraph justifies it:

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:

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.

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.

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.

Pavel Roskin <proski@gnu.org> writes:

That's a real concern, I should agree.

Junio C Hamano <junkio@cox.net> writes:

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.

Hi,

I think Junio is right: we should not force everybody not to use symlinks, only because there happens to be VFAT-, SMB- or HTTP-shared repositories. As Junio says, if there are people experiencing problems because they lack symbolic links, they should fix it.

On the other hand, I think it would be useful to be able to configure the behaviour via .git/config.

Ciao, Dscho

Dear diary, on Tue, Nov 15, 2005 at 12:09:42PM CET, I got a letter where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...

I'm ambivalent here. I would like to have just a single behaviour here, since the symbolic ref otherwise really does not get much testing. But I can also understand that we are breaking tools here.

Still, for the reason above, I think we should aim at the symbolic refs being the canonical format in the next major release after 1.0, giving users time to fix their tools. I can see no advantage in symlinks except the backwards compatibility - speed argument was presented, but I don't buy that until I see hard data supporting that.

Yes, I would very much like to have this. I still want to go symrefs-only for public repositories created for cg-admin-setuprepo, so that fetching over HTTP works properly.

Hi,

On Tue, 15 Nov 2005, Petr Baudis wrote:

<yousortofaskedforit> Well, I can see no good reason for symrefs, except for backwards compatibility! Modern systems do support symlinks, you know?

Let´s face it. The main target for git is not Windows users. If we really want to support all idiocies of all possible ones, how about this one:

If I clone a repository to a USB stick on cygwin, and try to access it from my iBook, it does not work, because for *backward compatibility* reasons, files fitting the 8.3 format are stored in UPPER CASE.

So, I would like to have support for UPPER CASE files in .git, please? And since I cannot do my own testing, please could you force everybody´s git to write OBJECTS and MASTER in UPPER CASE? </yousortofaskedforit>

Ciao, Dscho

What about less modern systems? I like to have tools that work on those, too.

Yes, but they are a worthy secondary target.

I don't think we want that, but I don't think the symref vs. symlink issue is an idiocy either.

Long and mixed-case filenames are supported almost universally. Why aren't you using FAT32 on your USB key? Even that decade-old filesystem supports them.

On Tue, 2005-11-15 at 15:24 +0100, Johannes Schindelin wrote:

You misunderstood me here. I meant backward compatibility with git wrappers, not with old operating systems.

I meant, the only reason we don't want symrefs to be used by default is because there are wrappers around git that only work with symlinks. So, if we change the default behavior in git now, those wrappers will break on new repositories.

That was pretty funny :-)

Actually, what's different about symlinks is that they go beyond the paradigm of one data stream per file. There are two data streams accessible through the symlink, one being the data in the file it points to, and the other being the path to that file.

This doesn't map well to many data transfer protocols. We don't want git to work only over protocols that have explicit support for symlinks.

One example is http, sometimes the only protocol allowed to transcend corporate firewalls.

Another, more controversial example is CVS. Sourceforge doesn't support git, but I could store my git database in Sourceforge CVS, and thus share it with other contributors. Not being able to put .git/HEAD there would be an annoyance.

I believe Cygwin developers were actually more concerned about symlinks damaged by SMB than about any issues with storing them locally. After all, Cygwin is quite good at emulating POSIX, including symlinks.

Returning to your example, 8.3 format is a problem with storage. Those are behind us. It's problems with transfer that are going to limit us.

Petr Baudis <pasky@suse.cz> writes:

Sorry, I must have missed that part. How does fetch-over-HTTP break with symlinked HEAD?

On Tue, 2005-11-15 at 09:05 -0800, Junio C Hamano wrote:

With symlinks, cogito doesn't know which branch it is fetching if the branch is not explicitly specified.

The old behavior was to fetch the "master" branch by default. Currently, cogito uses HEAD, but it cannot read the symlink, it can only read the SHA1. So, if somebody decides to use "cg-switch" on the public repository (admittedly not a very good idea), all the clients that are not using an explicit branch will unknowingly switch to another branch upon update.

It also could be useful for users to know the branch name. I, for one, would like to know if HEAD links to "stable" or "sandbox4crazyhacks", even if both have the same SHA1 at the moment.

On Tue, Nov 15, 2005 at 12:21:35PM -0500, Pavel Roskin wrote:

Symlinks can also be problematic for push-over-HTTP, since there are no guarantees about the backend on the server (eg. pushing into a subversion repo with mod_dav_svn.)

On Tue, 15 Nov 2005, Pavel Roskin wrote:

Hmm? Why not just use "git-symbolic-ref HEAD" to figure it out? That works with both symlinks and symrefs (and indeed, was added for that reason).

		Linus

Dear diary, on Tue, Nov 15, 2005 at 06:33:44PM CET, I got a letter where Linus Torvalds <torvalds@osdl.org> said that...

If you show me a way how to do git-symbolic-ref over HTTP, I will be most grateful. :-)

Seriously though, if people have huge problem with having symbolic refs by default, that's unfortunate since we have two possibilities which are not equally tested, but I can live with it - just give me a way to configure that behaviour per-repository, so that I can make GIT use symbolic refs in public repositories (or I can whip up a patch myself at the evening, after all...).

On Tue, 15 Nov 2005, Petr Baudis wrote:

Hmm, why do you care?

If you do a fetch over http, you'd just fetch HEAD directly. If that's just a SHA1 (like it will be with a symlink) you'll just use that as the branch (and don't care about what branch it was). And if it's a symref, you can see what the branch should be and fetch that. No?

			Linus

Pavel Roskin <proski@gnu.org> writes:

Ah, thanks.

git-clone-pack has the same problem.  It basically "guesses" by:

	- If the master branch exists, and the object name of
          the branch tip matches the object name of HEAD, assume
          HEAD points at master.  Even when there are other
          branches that happen to share the same branch head.

	- Otherwise, if there is a branch whose tip matches the
          object name of HEAD, assume HEAD points at it.  It
          just picks "one-of-them" if more than one branches
          match.

	- If there is no branch that matches HEAD, issue a
          warning and create HEAD that records the object name,
          not pointing anywhere.

To solve this generally we would need to extend what ls-remote returns, I suppose.

On Tue, 2005-11-15 at 13:18 +0100, Petr Baudis wrote:

I planned to write about symrefs long ago, and probably I waited for too long. I still hope it will be the default for 1.0 release, but if not, I hope the next release won't be too far away.

Agreed. By the way, the symref doesn't need to be called HEAD - it could be "trunk" or "main" or "default-branch".

Pavel Roskin <proski@gnu.org> writes:

The voice of reason comes from Pasky; I agree with this.

I think it is a bit too late for that, but please keep that patch; I'll hold on to it too.

I am in favor of that.  Something like this, perhaps:

	core.filemode = 1 # trustworthy
        core.usesymlink = 0 # new style 

Actually, I was thinking about changing get_sha1_basic() in sha1_name.c so that refs immediately under ${GIT_DIR-.git} are restricted to uppercase only. The other day I did

	$ git-update-ref linus blah

which created .git/linus in addition to .git/refs/heads/linus; this gives you considerable confusion.

On Tue, 2005-11-15 at 10:21 -0800, Junio C Hamano wrote:

OK, let's prepare for post-1.0 switchover then.

Thanks for implemented this.

Pavel Roskin <proski@gnu.org> writes:

Thank from me, too, Johannes.

On Tuesday 15 November 2005 13:18, Petr Baudis wrote:

Talking about versions...
Do we have an easy way to detect the format version of a git repository?
If not, I suggest git-init-db to add something like
	echo "1" > .git/version
and let all the git-tools which read/write any files in .git themself
test against version 1. Or is this overkill?

Josef

Pavel Roskin <proski@gnu.org> wrote:

StGIT has been fixed for this in the latest snapshot (but not in the latest release). It now uses "git-symbolic-ref HEAD" to get the name of the current branch.

On Tue, 2005-11-15 at 10:31 +0000, Catalin Marinas wrote:

Indeed.  I misinterpreted an error message.