{"thread":{"id":"2518","subject":"[PATCH] Disable USE_SYMLINK_HEAD by default","startedAt":"2005-11-15T05:59:50Z","lastAt":"2005-11-16T03:13:30Z","messageCount":24,"participants":["Pavel Roskin","Junio C Hamano","Catalin Marinas","Johannes Schindelin","Petr Baudis","Adrien Beau","Nick Hengeveld","Linus Torvalds","Josef Weidendorfer"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"11868","messageId":"1132034390.22207.18.camel@dv","threadId":"2518","inReplyTo":null,"subject":"[PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-11-15T05:59:50Z","receivedAt":"2005-11-15T05:59:50Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Disable USE_SYMLINK_HEAD by default. Recommend using it only for\ncompatibility with older software.\n\nTreat USE_SYMLINK_HEAD like other optional defines - check whether it's\ndefined, not its value.\n\nSigned-off-by: Pavel Roskin \n\n---\nApplying this patch before 1.0 may be controversial, but I think there\nis a very good reason for that. There should be exactly one git 1.0\nrepository format. Now we have two that are present in the sources and\nthat have received testing from the git users.\n\nOf those two formats, I prefer the one that is platform independent and\nnot very demanding with regard to filesystems and transfer protocols.\nThat format should be good enough so that we don't plan to change it as\nsoon as version 1.0 is released. Any third party software claiming to\nsupport git 1.0 should need to support one repository format.\n\n\ndiff --git a/Makefile b/Makefile\nindex 63cb998..585552e 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -18,6 +18,10 @@\n #\n # Define NO_STRCASESTR if you don't have strcasestr.\n #\n+# Define USE_SYMLINK_HEAD if you want .git/HEAD to be a symbolic link.\n+# This feature is phased out, enable it only for compatibility with other\n+# software. Don't enable it on Windows.\n+#\n # Define PPC_SHA1 environment variable when running make to make use of\n # a bundled SHA1 routine optimized for PowerPC.\n #\n@@ -210,7 +214,6 @@ ifeq ($(uname_O),Cygwin)\n \tNEEDS_LIBICONV = YesPlease\n \tNO_IPV6 = YesPlease\n \tX = .exe\n-\tALL_CFLAGS += -DUSE_SYMLINK_HEAD=0\n endif\n ifeq ($(uname_S),OpenBSD)\n \tNO_STRCASESTR = YesPlease\ndiff --git a/refs.c b/refs.c\nindex a52b038..9b88742 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -6,10 +6,6 @@\n /* We allow \"recursive\" symbolic refs. Only within reason, though */\n #define MAXDEPTH 5\n \n-#ifndef USE_SYMLINK_HEAD\n-#define USE_SYMLINK_HEAD 1\n-#endif\n-\n int validate_symref(const char *path)\n {\n \tstruct stat st;\n@@ -120,7 +116,7 @@ int create_symref(const char *git_HEAD, \n \tchar ref[1000];\n \tint fd, len, written;\n \n-#if USE_SYMLINK_HEAD\n+#ifdef USE_SYMLINK_HEAD\n \tunlink(git_HEAD);\n \tif (!symlink(refs_heads_master, git_HEAD))\n \t\treturn 0;\n\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"11870","messageId":"7vveyuqto5.fsf@assigned-by-dhcp.cox.net","threadId":"2518","inReplyTo":"1132034390.22207.18.camel@dv","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-15T07:03:38Z","receivedAt":"2005-11-15T07:03:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin writes:\n\n> Applying this patch before 1.0 may be controversial,...\n\nIf I am not mistaken, I thought the last thread on the list\nshowed general consensus that symlinks were preferred when\navailable. So applying this patch anytime would be\ncontroversial...\n\n> but I think there is a very good reason for that.\n\nWhich is...? I do not think this paragraph justifies it:\n\n> There should be exactly one git 1.0 repository format. Now we\n> have two that are present in the sources and that have\n> received testing from the git users.\n\nThe one format is that .git/HEAD can either be a symlink or\nregular file text symref; both variants are tested -- wouldn't\nthat be good enough?\n\nThe only thing I can think of that might be inconvenient is if\nyou try doing \"cp -a\" off of a filesystem that supports symlinks\nto another filesystem that does not -- probably that would fail\ncopying the symlinked .git/HEAD. But if that is the problem,\nyou could always git-clone, which should do the right thing, I\nthink.\n"},{"id":"11877","messageId":"1132042427.3512.50.camel@dv","threadId":"2518","inReplyTo":"7vveyuqto5.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-11-15T08:13:47Z","receivedAt":"2005-11-15T08:13:47Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Mon, 2005-11-14 at 23:03 -0800, Junio C Hamano wrote:\n> Pavel Roskin writes:\n> \n> > Applying this patch before 1.0 may be controversial,...\n> \n> If I am not mistaken, I thought the last thread on the list\n> showed general consensus that symlinks were preferred when\n> available. So applying this patch anytime would be\n> controversial...\n\nI must have missed that. If you mean \"Re: Getting rid of symlinks\nin .git?\", I don't see any such consensus there. The discussion drifts\nto insignificant details, and I see arguments like \"I couldn't care\nless\" and speculations about speed without any hard data at hand.\n\n> > but I think there is a very good reason for that.\n> \n> Which is...? I do not think this paragraph justifies it:\n> \n> > There should be exactly one git 1.0 repository format. Now we\n> > have two that are present in the sources and that have\n> > received testing from the git users.\n> \n> The one format is that .git/HEAD can either be a symlink or\n> regular file text symref; both variants are tested -- wouldn't\n> that be good enough?\n\nNo. Even if git itself is tested, other tools are not. What's worse,\nthe developers of those tools don't even know they are supposed to test\nfor two HEAD formats unless they track git changes and mailing lists\nvery carefully.\n\nIn particular, StGIT still needs fixing.\n\n> The only thing I can think of that might be inconvenient is if\n> you try doing \"cp -a\" off of a filesystem that supports symlinks\n> to another filesystem that does not -- probably that would fail\n> copying the symlinked .git/HEAD. But if that is the problem,\n> you could always git-clone, which should do the right thing, I\n> think.\n\nI'm talking from my experience now. If there is an option, there are\nusers that have it enabled and those who have it disabled (by\ndefinition). As is often happens, one of the configurations is more\npopular with developers. The other configuration almost inevitably\nstarts suffering from the \"bit rot\".\n\nIt could have been prevented if the format choice was encapsulated by\ngit prior to its introduction. But git-symbolic-ref didn't exist before\nsymrefs were implemented. Old code outside git accesses .git/HEAD\nmanually. Fixing git alone is not enough if git files are accessed\nwithout git.\n\nExtra complexity of any format discourages third party applications or\nmakes them more complex and less safe to use.\n\nI can understand if the complexity has a balance of requirements issue\nbehind it. For example, coexistence of packed and unpacked files comes\nfrom the conflicting requirements to handle files quickly and not to\nconsume too much hard disk space and bandwidth.\n\nBut there is no strong (compared to portability) reason to have\nsymlinks, except maybe backward compatibility. It's a weak argument\nbefore 1.0 release. Let's not wait until it becomes stronger.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"11879","messageId":"7vpsp2qpx4.fsf@assigned-by-dhcp.cox.net","threadId":"2518","inReplyTo":"1132042427.3512.50.camel@dv","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-15T08:24:39Z","receivedAt":"2005-11-15T08:24:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin writes:\n\n> In particular, StGIT still needs fixing.\n>\n>> The only thing I can think of that might be inconvenient is if\n>> you try doing \"cp -a\" off of a filesystem that supports symlinks\n>> to another filesystem that does not -- probably that would fail\n>> copying the symlinked .git/HEAD. But if that is the problem,\n>> you could always git-clone, which should do the right thing, I\n>> think.\n>\n> I'm talking from my experience now. If there is an option, there are\n> users that have it enabled and those who have it disabled (by\n> definition). As is often happens, one of the configurations is more\n> popular with developers. The other configuration almost inevitably\n> starts suffering from the \"bit rot\".\n\nThat's a real concern, I should agree.\n"},{"id":"11884","messageId":"7vd5l2mco1.fsf@assigned-by-dhcp.cox.net","threadId":"2518","inReplyTo":"7vpsp2qpx4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-15T10:24:30Z","receivedAt":"2005-11-15T10:24:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Pavel Roskin writes:\n>\n>> In particular, StGIT still needs fixing.\n>>> ...\n>> I'm talking from my experience now. If there is an option, there are\n>> users that have it enabled and those who have it disabled (by\n>> definition). As is often happens, one of the configurations is more\n>> popular with developers. The other configuration almost inevitably\n>> starts suffering from the \"bit rot\".\n>\n> That's a real concern, I should agree.\n\nI think I need to qualify this comment. It is a real concern\nbecause we need to know when it is safe to start using textual\nsymrefs everywhere, *if* we would want to do that switch.\n\nI wonder how ready StGIT and Cogito are, but also I wonder how\nready other things are. People built homebrew scripts around\ngit without calling them Porcelains, and git is designed to be\nused that way. We do not know how many things we are breaking\nif we switch to do textual symrefs by default.\n\nI just checked the latest gitweb, and it does not seem to be\nready. I do not, however, necessarily think it is a high\npriority problem. It does not feel to me a realistic issue that\nyou cannot serve a public repository on a filesystem incapable\nof symlinks via getweb. This change is breaking things for\ngitweb running on kernel.org machines without real benefit.\n\nThinking about it a bit more, the current setup to use symlinks\non systems that supports them, and textual symrefs on others, is\nlooking more and more sensible to me. If supporting\nsymlink-challenged filesystems become a real issue for a \"third\nparty tool\", certainly that will be updated, because people\nwould want it. Switching to do textual symrefs by default\neverywhere is a way to *force* people to scramble and update\ntheir scripts everywhere, but I am not so sure that is worth it;\nI cannot justify why I'd be forcing them to do so, especially if\nsupporting VFAT is a low priority for some of the tools.\n\n\"Bit rot\" may first seem a concern, but actually it is not. I\nsuspect that serverish applications such as gitweb view\nsupporting symlink-challenged filesystems as a lower priority\ntask, while more client-oriented applications rate it higher.\nThe core support for textual symrefs cannot afford to rot as\nlong as some Porcelain needs it, and worrying about it would not\nbe a good justification to break everybody \"just to see what\nbreaks\". On the other hand, if the support for textual symrefs\nrot, it probably deserves to --- the only reason that would\nhappen would be because nobody uses them.\n\nIOW, if we see real breakage in either git itself or Porcelains\nthat use git, send in fixes to appropriate parties. I think\nthat's being constructive. Otherwise, let's not break things\njust for the sake of consistency. I do not think that is\nhelping anything.\n"},{"id":"11885","messageId":"tnxek5i42y5.fsf@arm.com","threadId":"2518","inReplyTo":"1132042427.3512.50.camel@dv","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-11-15T10:31:46Z","receivedAt":"2005-11-15T10:31:46Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Pavel Roskin wrote:\n> On Mon, 2005-11-14 at 23:03 -0800, Junio C Hamano wrote:\n>> The one format is that .git/HEAD can either be a symlink or\n>> regular file text symref; both variants are tested -- wouldn't\n>> that be good enough?\n>\n> No. Even if git itself is tested, other tools are not. What's worse,\n> the developers of those tools don't even know they are supposed to test\n> for two HEAD formats unless they track git changes and mailing lists\n> very carefully.\n>\n> In particular, StGIT still needs fixing.\n\nStGIT has been fixed for this in the latest snapshot (but not in the\nlatest release). It now uses \"git-symbolic-ref HEAD\" to get the name\nof the current branch.\n\n-- \nCatalin\n"},{"id":"11887","messageId":"Pine.LNX.4.63.0511151207070.21671@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2518","inReplyTo":"7vd5l2mco1.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-15T11:09:42Z","receivedAt":"2005-11-15T11:09:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nI think Junio is right: we should not force everybody not to use symlinks, \nonly because there happens to be VFAT-, SMB- or HTTP-shared repositories. \nAs Junio says, if there are people experiencing problems because they lack \nsymbolic links, they should fix it.\n\nOn the other hand, I think it would be useful to be able to configure the \nbehaviour via .git/config.\n\nCiao,\nDscho\n"},{"id":"11891","messageId":"20051115121854.GV30496@pasky.or.cz","threadId":"2518","inReplyTo":"Pine.LNX.4.63.0511151207070.21671@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-15T12:18:54Z","receivedAt":"2005-11-15T12:18:54Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Nov 15, 2005 at 12:09:42PM CET, I got a letter\nwhere Johannes Schindelin said that...\n> I think Junio is right: we should not force everybody not to use symlinks, \n> only because there happens to be VFAT-, SMB- or HTTP-shared repositories. \n> As Junio says, if there are people experiencing problems because they lack \n> symbolic links, they should fix it.\n\nI'm ambivalent here. I would like to have just a single behaviour here,\nsince the symbolic ref otherwise really does not get much testing. But I\ncan also understand that we are breaking tools here.\n\nStill, for the reason above, I think we should aim at the symbolic refs\nbeing the canonical format in the next major release after 1.0, giving\nusers time to fix their tools. I can see no advantage in symlinks except\nthe backwards compatibility - speed argument was presented, but I don't\nbuy that until I see hard data supporting that.\n\n> On the other hand, I think it would be useful to be able to configure the \n> behaviour via .git/config.\n\nYes, I would very much like to have this. I still want to go\nsymrefs-only for public repositories created for cg-admin-setuprepo, so\nthat fetching over HTTP works properly.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11895","messageId":"Pine.LNX.4.63.0511151518210.23020@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2518","inReplyTo":"20051115121854.GV30496@pasky.or.cz","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-15T14:24:58Z","receivedAt":"2005-11-15T14:24:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 15 Nov 2005, Petr Baudis wrote:\n\n> Dear diary, on Tue, Nov 15, 2005 at 12:09:42PM CET, I got a letter\n> where Johannes Schindelin said that...\n> > I think Junio is right: we should not force everybody not to use \n> > symlinks, only because there happens to be VFAT-, SMB- or HTTP-shared \n> > repositories. As Junio says, if there are people experiencing problems \n> > because they lack symbolic links, they should fix it.\n> \n> I'm ambivalent here. I would like to have just a single behaviour here, \n> since the symbolic ref otherwise really does not get much testing. But I \n> can also understand that we are breaking tools here.\n> \n> Still, for the reason above, I think we should aim at the symbolic refs\n> being the canonical format in the next major release after 1.0, giving\n> users time to fix their tools. I can see no advantage in symlinks except\n> the backwards compatibility - speed argument was presented, but I don't\n> buy that until I see hard data supporting that.\n\n\nWell, I can see no good reason for symrefs, except for backwards \ncompatibility! Modern systems do support symlinks, you know?\n\nLet´s face it. The main target for git is not Windows users. If we really \nwant to support all idiocies of all possible ones, how about this one:\n\nIf I clone a repository to a USB stick on cygwin, and try to access it \nfrom my iBook, it does not work, because for *backward compatibility* \nreasons, files fitting the 8.3 format are stored in UPPER CASE.\n\nSo, I would like to have support for UPPER CASE files in .git, please? And \nsince I cannot do my own testing, please could you force everybody´s git \nto write OBJECTS and MASTER in UPPER CASE?\n\n\nCiao,\nDscho\n"},{"id":"11900","messageId":"94fc236b0511150737x7f0977ffmf9eb4a875715e7a0@mail.gmail.com","threadId":"2518","inReplyTo":"Pine.LNX.4.63.0511151518210.23020@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Adrien Beau","fromEmail":"adrienbeau@gmail.com","sentAt":"2005-11-15T15:37:43Z","receivedAt":"2005-11-15T15:37:43Z","isPatch":true,"sender":{"key":"adrienbeau@gmail.com","avatar":null},"body":"> Well, I can see no good reason for symrefs, except for backwards\n> compatibility! Modern systems do support symlinks, you know?\n\nWhat about less modern systems? I like to have tools that work on those, too.\n\n> Let´s face it. The main target for git is not Windows users.\n\nYes, but they are a worthy secondary target.\n\n> If we really want to support all idiocies of all possible ones,\n\nI don't think we want that, but I don't think the symref vs. symlink\nissue is an idiocy either.\n\n> how about this one:\n>\n> If I clone a repository to a USB stick on cygwin, and try to access it\n> from my iBook, it does not work, because for *backward compatibility*\n> reasons, files fitting the 8.3 format are stored in UPPER CASE.\n>\n> So, I would like to have support for UPPER CASE files in .git, please? And\n> since I cannot do my own testing, please could you force everybody´s git\n> to write OBJECTS and MASTER in UPPER CASE?\n\nLong and mixed-case filenames are supported almost universally. Why\naren't you using FAT32 on your USB key? Even that decade-old\nfilesystem supports them.\n"},{"id":"11907","messageId":"1132072062.25640.10.camel@dv","threadId":"2518","inReplyTo":"tnxek5i42y5.fsf@arm.com","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-11-15T16:27:42Z","receivedAt":"2005-11-15T16:27:42Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Tue, 2005-11-15 at 10:31 +0000, Catalin Marinas wrote:\n> Pavel Roskin wrote:\n> > In particular, StGIT still needs fixing.\n> \n> StGIT has been fixed for this in the latest snapshot (but not in the\n> latest release). It now uses \"git-symbolic-ref HEAD\" to get the name\n> of the current branch.\n\nIndeed. I misinterpreted an error message.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"11908","messageId":"1132073436.25640.32.camel@dv","threadId":"2518","inReplyTo":"Pine.LNX.4.63.0511151518210.23020@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-11-15T16:50:36Z","receivedAt":"2005-11-15T16:50:36Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Tue, 2005-11-15 at 15:24 +0100, Johannes Schindelin wrote:\n> \n> Well, I can see no good reason for symrefs, except for backwards \n> compatibility! Modern systems do support symlinks, you know?\n\nYou misunderstood me here. I meant backward compatibility with git\nwrappers, not with old operating systems.\n\nI meant, the only reason we don't want symrefs to be used by default is\nbecause there are wrappers around git that only work with symlinks. So,\nif we change the default behavior in git now, those wrappers will break\non new repositories.\n\n> Let´s face it. The main target for git is not Windows users. If we really \n> want to support all idiocies of all possible ones, how about this one:\n> \n> If I clone a repository to a USB stick on cygwin, and try to access it \n> from my iBook, it does not work, because for *backward compatibility* \n> reasons, files fitting the 8.3 format are stored in UPPER CASE.\n> \n> So, I would like to have support for UPPER CASE files in .git, please? And \n> since I cannot do my own testing, please could you force everybody´s git \n> to write OBJECTS and MASTER in UPPER CASE?\n\nThat was pretty funny :-)\n\nActually, what's different about symlinks is that they go beyond the\nparadigm of one data stream per file. There are two data streams\naccessible through the symlink, one being the data in the file it points\nto, and the other being the path to that file.\n\nThis doesn't map well to many data transfer protocols. We don't want\ngit to work only over protocols that have explicit support for symlinks.\n\nOne example is http, sometimes the only protocol allowed to transcend\ncorporate firewalls.\n\nAnother, more controversial example is CVS. Sourceforge doesn't support\ngit, but I could store my git database in Sourceforge CVS, and thus\nshare it with other contributors. Not being able to put .git/HEAD there\nwould be an annoyance.\n\nI believe Cygwin developers were actually more concerned about symlinks\ndamaged by SMB than about any issues with storing them locally. After\nall, Cygwin is quite good at emulating POSIX, including symlinks.\n\nReturning to your example, 8.3 format is a problem with storage. Those\nare behind us. It's problems with transfer that are going to limit us.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"11909","messageId":"7v8xvpn8ne.fsf@assigned-by-dhcp.cox.net","threadId":"2518","inReplyTo":"20051115121854.GV30496@pasky.or.cz","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-15T17:05:57Z","receivedAt":"2005-11-15T17:05:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Yes, I would very much like to have this. I still want to go\n> symrefs-only for public repositories created for cg-admin-setuprepo, so\n> that fetching over HTTP works properly.\n\nSorry, I must have missed that part. How does fetch-over-HTTP\nbreak with symlinked HEAD?\n"},{"id":"11910","messageId":"1132074375.25640.47.camel@dv","threadId":"2518","inReplyTo":"20051115121854.GV30496@pasky.or.cz","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-11-15T17:06:15Z","receivedAt":"2005-11-15T17:06:15Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Tue, 2005-11-15 at 13:18 +0100, Petr Baudis wrote:\n> Dear diary, on Tue, Nov 15, 2005 at 12:09:42PM CET, I got a letter\n> where Johannes Schindelin said that...\n> > I think Junio is right: we should not force everybody not to use symlinks, \n> > only because there happens to be VFAT-, SMB- or HTTP-shared repositories. \n> > As Junio says, if there are people experiencing problems because they lack \n> > symbolic links, they should fix it.\n> \n> I'm ambivalent here. I would like to have just a single behaviour here,\n> since the symbolic ref otherwise really does not get much testing. But I\n> can also understand that we are breaking tools here.\n> \n> Still, for the reason above, I think we should aim at the symbolic refs\n> being the canonical format in the next major release after 1.0, giving\n> users time to fix their tools. I can see no advantage in symlinks except\n> the backwards compatibility - speed argument was presented, but I don't\n> buy that until I see hard data supporting that.\n\nI planned to write about symrefs long ago, and probably I waited for too\nlong. I still hope it will be the default for 1.0 release, but if not,\nI hope the next release won't be too far away.\n\n> > On the other hand, I think it would be useful to be able to configure the \n> > behaviour via .git/config.\n> \n> Yes, I would very much like to have this. I still want to go\n> symrefs-only for public repositories created for cg-admin-setuprepo, so\n> that fetching over HTTP works properly.\n\nAgreed. By the way, the symref doesn't need to be called HEAD - it\ncould be \"trunk\" or \"main\" or \"default-branch\".\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"11913","messageId":"1132075295.25640.59.camel@dv","threadId":"2518","inReplyTo":"7v8xvpn8ne.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-11-15T17:21:35Z","receivedAt":"2005-11-15T17:21:35Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Tue, 2005-11-15 at 09:05 -0800, Junio C Hamano wrote:\n> Petr Baudis writes:\n> \n> > Yes, I would very much like to have this. I still want to go\n> > symrefs-only for public repositories created for cg-admin-setuprepo, so\n> > that fetching over HTTP works properly.\n> \n> Sorry, I must have missed that part. How does fetch-over-HTTP\n> break with symlinked HEAD?\n\nWith symlinks, cogito doesn't know which branch it is fetching if the\nbranch is not explicitly specified.\n\nThe old behavior was to fetch the \"master\" branch by default.\nCurrently, cogito uses HEAD, but it cannot read the symlink, it can only\nread the SHA1. So, if somebody decides to use \"cg-switch\" on the public\nrepository (admittedly not a very good idea), all the clients that are\nnot using an explicit branch will unknowingly switch to another branch\nupon update.\n\nIt also could be useful for users to know the branch name. I, for one,\nwould like to know if HEAD links to \"stable\" or \"sandbox4crazyhacks\",\neven if both have the same SHA1 at the moment.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"11915","messageId":"20051115173234.GC3793@reactrix.com","threadId":"2518","inReplyTo":"1132075295.25640.59.camel@dv","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2005-11-15T17:32:34Z","receivedAt":"2005-11-15T17:32:34Z","isPatch":true,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Tue, Nov 15, 2005 at 12:21:35PM -0500, Pavel Roskin wrote:\n\n> > Sorry, I must have missed that part. How does fetch-over-HTTP\n> > break with symlinked HEAD?\n\nSymlinks can also be problematic for push-over-HTTP, since there are no\nguarantees about the backend on the server (eg. pushing into a\nsubversion repo with mod_dav_svn.)\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"},{"id":"11916","messageId":"Pine.LNX.4.64.0511150931010.3945@g5.osdl.org","threadId":"2518","inReplyTo":"1132075295.25640.59.camel@dv","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-15T17:33:44Z","receivedAt":"2005-11-15T17:33:44Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 15 Nov 2005, Pavel Roskin wrote:\n> \n> With symlinks, cogito doesn't know which branch it is fetching if the\n> branch is not explicitly specified.\n> \n> The old behavior was to fetch the \"master\" branch by default.\n> Currently, cogito uses HEAD, but it cannot read the symlink, it can only\n> read the SHA1. \n\nHmm? Why not just use \"git-symbolic-ref HEAD\" to figure it out? That works \nwith both symlinks and symrefs (and indeed, was added for that reason).\n\n\t\tLinus\n"},{"id":"11917","messageId":"20051115174213.GO16061@pasky.or.cz","threadId":"2518","inReplyTo":"Pine.LNX.4.64.0511150931010.3945@g5.osdl.org","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-15T17:42:13Z","receivedAt":"2005-11-15T17:42:13Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Nov 15, 2005 at 06:33:44PM CET, I got a letter\nwhere Linus Torvalds said that...\n> On Tue, 15 Nov 2005, Pavel Roskin wrote:\n> > \n> > With symlinks, cogito doesn't know which branch it is fetching if the\n> > branch is not explicitly specified.\n> > \n> > The old behavior was to fetch the \"master\" branch by default.\n> > Currently, cogito uses HEAD, but it cannot read the symlink, it can only\n> > read the SHA1. \n> \n> Hmm? Why not just use \"git-symbolic-ref HEAD\" to figure it out? That works \n> with both symlinks and symrefs (and indeed, was added for that reason).\n\nIf you show me a way how to do git-symbolic-ref over HTTP, I will be\nmost grateful. :-)\n\nSeriously though, if people have huge problem with having symbolic refs\nby default, that's unfortunate since we have two possibilities which are\nnot equally tested, but I can live with it - just give me a way to\nconfigure that behaviour per-repository, so that I can make GIT use\nsymbolic refs in public repositories (or I can whip up a patch myself at\nthe evening, after all...).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11918","messageId":"Pine.LNX.4.64.0511150957220.3945@g5.osdl.org","threadId":"2518","inReplyTo":"20051115174213.GO16061@pasky.or.cz","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-15T18:01:32Z","receivedAt":"2005-11-15T18:01:32Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 15 Nov 2005, Petr Baudis wrote:\n> \n> If you show me a way how to do git-symbolic-ref over HTTP, I will be\n> most grateful. :-)\n\nHmm, why do you care?\n\nIf you do a fetch over http, you'd just fetch HEAD directly. If that's \njust a SHA1 (like it will be with a symlink) you'll just use that as the \nbranch (and don't care about what branch it was). And if it's a symref, \nyou can see what the branch should be and fetch that. No?\n\n\t\t\tLinus\n"},{"id":"11926","messageId":"7v4q6dn5j8.fsf@assigned-by-dhcp.cox.net","threadId":"2518","inReplyTo":"1132075295.25640.59.camel@dv","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-15T18:13:15Z","receivedAt":"2005-11-15T18:13:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin writes:\n\n> On Tue, 2005-11-15 at 09:05 -0800, Junio C Hamano wrote:\n>> Petr Baudis writes:\n>> \n>> > Yes, I would very much like to have this. I still want to go\n>> > symrefs-only for public repositories created for cg-admin-setuprepo, so\n>> > that fetching over HTTP works properly.\n>> \n>> Sorry, I must have missed that part. How does fetch-over-HTTP\n>> break with symlinked HEAD?\n>\n> With symlinks, cogito doesn't know which branch it is fetching if the\n> branch is not explicitly specified.\n\nAh, thanks.\n\ngit-clone-pack has the same problem. It basically \"guesses\" by:\n\n\t- If the master branch exists, and the object name of\n the branch tip matches the object name of HEAD, assume\n HEAD points at master. Even when there are other\n branches that happen to share the same branch head.\n\n\t- Otherwise, if there is a branch whose tip matches the\n object name of HEAD, assume HEAD points at it. It\n just picks \"one-of-them\" if more than one branches\n match.\n\n\t- If there is no branch that matches HEAD, issue a\n warning and create HEAD that records the object name,\n not pointing anywhere.\n\nTo solve this generally we would need to extend what ls-remote\nreturns, I suppose.\n"},{"id":"11928","messageId":"7vy83plqlr.fsf@assigned-by-dhcp.cox.net","threadId":"2518","inReplyTo":"1132074375.25640.47.camel@dv","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-15T18:21:04Z","receivedAt":"2005-11-15T18:21:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin writes:\n\n> On Tue, 2005-11-15 at 13:18 +0100, Petr Baudis wrote:\n>>\n>> I'm ambivalent here. I would like to have just a single behaviour here,\n>> since the symbolic ref otherwise really does not get much testing. But I\n>> can also understand that we are breaking tools here.\n>> \n>> Still, for the reason above, I think we should aim at the symbolic refs\n>> being the canonical format in the next major release after 1.0, giving\n>> users time to fix their tools. I can see no advantage in symlinks except\n>> the backwards compatibility...\n\nThe voice of reason comes from Pasky; I agree with this.\n\n> I planned to write about symrefs long ago, and probably I waited for too\n> long. I still hope it will be the default for 1.0 release, but if not,\n> I hope the next release won't be too far away.\n\nI think it is a bit too late for that, but please keep that\npatch; I'll hold on to it too.\n\n>> > On the other hand, I think it would be useful to be able to configure the \n>> > behaviour via .git/config.\n>> \n>> Yes, I would very much like to have this.\n\nI am in favor of that. Something like this, perhaps:\n\n\tcore.filemode = 1 # trustworthy\n core.usesymlink = 0 # new style \n\n> Agreed. By the way, the symref doesn't need to be called HEAD - it\n> could be \"trunk\" or \"main\" or \"default-branch\".\n\nActually, I was thinking about changing get_sha1_basic() in\nsha1_name.c so that refs immediately under ${GIT_DIR-.git} are\nrestricted to uppercase only. The other day I did\n\n\t$ git-update-ref linus blah\n\nwhich created .git/linus in addition to .git/refs/heads/linus;\nthis gives you considerable confusion.\n"},{"id":"11973","messageId":"200511160205.43443.Josef.Weidendorfer@gmx.de","threadId":"2518","inReplyTo":"20051115121854.GV30496@pasky.or.cz","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-16T01:05:43Z","receivedAt":"2005-11-16T01:05:43Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 15 November 2005 13:18, Petr Baudis wrote:\n> being the canonical format in the next major release after 1.0, giving\n\nTalking about versions...\nDo we have an easy way to detect the format version of a git repository?\nIf not, I suggest git-init-db to add something like\n\techo \"1\" > .git/version\nand let all the git-tools which read/write any files in .git themself\ntest against version 1. Or is this overkill?\n\nJosef\n"},{"id":"11979","messageId":"1132106171.18941.2.camel@dv","threadId":"2518","inReplyTo":"7vy83plqlr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-11-16T01:56:11Z","receivedAt":"2005-11-16T01:56:11Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Tue, 2005-11-15 at 10:21 -0800, Junio C Hamano wrote:\n> Pavel Roskin writes:\n\n> The voice of reason comes from Pasky; I agree with this.\n\nOK, let's prepare for post-1.0 switchover then.\n\n> I am in favor of that. Something like this, perhaps:\n> \n> \tcore.filemode = 1 # trustworthy\n> core.usesymlink = 0 # new style \n\nThanks for implemented this.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"11988","messageId":"7virutcmjp.fsf@assigned-by-dhcp.cox.net","threadId":"2518","inReplyTo":"1132106171.18941.2.camel@dv","subject":"Re: [PATCH] Disable USE_SYMLINK_HEAD by default","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-16T03:13:30Z","receivedAt":"2005-11-16T03:13:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin writes:\n\n>> I am in favor of that. Something like this, perhaps:\n>> \n>> \tcore.filemode = 1 # trustworthy\n>> core.usesymlink = 0 # new style \n>\n> Thanks for implemented this.\n\nThank from me, too, Johannes.\n"}]}