[PATCH] Disable USE_SYMLINK_HEAD by default

[PATCH] Disable USE_SYMLINK_HEAD by default

[Pavel Roskin]

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.


diff --git a/Makefile b/Makefile
index 63cb998..585552e 100644
--- a/Makefile
+++ b/Makefile
@@ -18,6 +18,10 @@
 #
 # Define NO_STRCASESTR if you don't have strcasestr.
 #
+# Define USE_SYMLINK_HEAD if you want .git/HEAD to be a symbolic link.
+# This feature is phased out, enable it only for compatibility with other
+# software.  Don't enable it on Windows.
+#
 # Define PPC_SHA1 environment variable when running make to make use of
 # a bundled SHA1 routine optimized for PowerPC.
 #
@@ -210,7 +214,6 @@ ifeq ($(uname_O),Cygwin)
 	NEEDS_LIBICONV = YesPlease
 	NO_IPV6 = YesPlease
 	X = .exe
-	ALL_CFLAGS += -DUSE_SYMLINK_HEAD=0
 endif
 ifeq ($(uname_S),OpenBSD)
 	NO_STRCASESTR = YesPlease
diff --git a/refs.c b/refs.c
index a52b038..9b88742 100644
--- a/refs.c
+++ b/refs.c
@@ -6,10 +6,6 @@
 /* We allow "recursive" symbolic refs. Only within reason, though */
 #define MAXDEPTH 5
 
-#ifndef USE_SYMLINK_HEAD
-#define USE_SYMLINK_HEAD 1
-#endif
-
 int validate_symref(const char *path)
 {
 	struct stat st;
@@ -120,7 +116,7 @@ int create_symref(const char *git_HEAD, 
 	char ref[1000];
 	int fd, len, written;
 
-#if USE_SYMLINK_HEAD
+#ifdef USE_SYMLINK_HEAD
 	unlink(git_HEAD);
 	if (!symlink(refs_heads_master, git_HEAD))
 		return 0;


-- 
Regards,
Pavel Roskin

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Junio C Hamano]

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

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

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Pavel Roskin]

On Mon, 2005-11-14 at 23:03 -0800, Junio C Hamano wrote:
> 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.

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

> 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

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Junio C Hamano]

Pavel Roskin <proski@gnu.org> writes:

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

That's a real concern, I should agree.

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Junio C Hamano]

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

> Pavel Roskin <proski@gnu.org> writes:
>
>> 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".
>
> 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.

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Johannes Schindelin]

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

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Petr Baudis]

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

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.

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

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.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1796 bytes --]

Hi,

On Tue, 15 Nov 2005, Petr Baudis wrote:

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

<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

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Adrien Beau]

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

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

> Let´s face it. The main target for git is not Windows users.

Yes, but they are a worthy secondary target.

> If we really want to support all idiocies of all possible ones,

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

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

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.

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Pavel Roskin]

On Tue, 2005-11-15 at 15:24 +0100, Johannes Schindelin wrote:
> <yousortofaskedforit>
> Well, I can see no good reason for symrefs, except for backwards 
> compatibility! Modern systems do support symlinks, you know?

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.

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

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.

-- 
Regards,
Pavel Roskin

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

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

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

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Pavel Roskin]

On Tue, 2005-11-15 at 09:05 -0800, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
> 
> > 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.
> 
> Sorry, I must have missed that part.  How does fetch-over-HTTP
> break with symlinked HEAD?

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.

-- 
Regards,
Pavel Roskin

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Nick Hengeveld]

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

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

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

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Linus Torvalds]

On Tue, 15 Nov 2005, Pavel Roskin 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. 

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

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Petr Baudis]

Dear diary, on Tue, Nov 15, 2005 at 06:33:44PM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> On Tue, 15 Nov 2005, Pavel Roskin 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. 
> 
> 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).

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

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Linus Torvalds]

On Tue, 15 Nov 2005, Petr Baudis wrote:
> 
> If you show me a way how to do git-symbolic-ref over HTTP, I will be
> most grateful. :-)

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

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Junio C Hamano]

Pavel Roskin <proski@gnu.org> writes:

> On Tue, 2005-11-15 at 09:05 -0800, Junio C Hamano wrote:
>> Petr Baudis <pasky@suse.cz> writes:
>> 
>> > 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.
>> 
>> Sorry, I must have missed that part.  How does fetch-over-HTTP
>> break with symlinked HEAD?
>
> With symlinks, cogito doesn't know which branch it is fetching if the
> branch is not explicitly specified.

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.

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Pavel Roskin]

On Tue, 2005-11-15 at 13:18 +0100, Petr Baudis wrote:
> 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 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.
> 
> 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.

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.

> > On the other hand, I think it would be useful to be able to configure the 
> > behaviour via .git/config.
> 
> 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.

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

-- 
Regards,
Pavel Roskin

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Junio C Hamano]

Pavel Roskin <proski@gnu.org> writes:

> On Tue, 2005-11-15 at 13:18 +0100, Petr Baudis wrote:
>>
>> 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...

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

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

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

>> > On the other hand, I think it would be useful to be able to configure the 
>> > behaviour via .git/config.
>> 
>> Yes, I would very much like to have this.

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

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

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

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.

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Pavel Roskin]

On Tue, 2005-11-15 at 10:21 -0800, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:

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

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

> I am in favor of that.  Something like this, perhaps:
> 
> 	core.filemode = 1 # trustworthy
>         core.usesymlink = 0 # new style 

Thanks for implemented this.

-- 
Regards,
Pavel Roskin

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Junio C Hamano]

Pavel Roskin <proski@gnu.org> writes:

>> I am in favor of that.  Something like this, perhaps:
>> 
>> 	core.filemode = 1 # trustworthy
>>         core.usesymlink = 0 # new style 
>
> Thanks for implemented this.

Thank from me, too, Johannes.

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Josef Weidendorfer]

On Tuesday 15 November 2005 13:18, Petr Baudis wrote:
> being the canonical format in the next major release after 1.0, giving

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

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Catalin Marinas]

Pavel Roskin <proski@gnu.org> wrote:
> On Mon, 2005-11-14 at 23:03 -0800, Junio C Hamano wrote:
>> 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.

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.

-- 
Catalin

Re: [PATCH] Disable USE_SYMLINK_HEAD by default

[Pavel Roskin]

On Tue, 2005-11-15 at 10:31 +0000, Catalin Marinas wrote:
> Pavel Roskin <proski@gnu.org> wrote:
> > In particular, StGIT still needs fixing.
> 
> 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.

Indeed.  I misinterpreted an error message.

-- 
Regards,
Pavel Roskin