Getting rid of symlinks in .git?

Getting rid of symlinks in .git?

[Petr Baudis]

I'm deliberately breaking up the thread here, not to make the list
reading even more difficult for all the poor readers not so interested
in electronic archaeology (but I feel better after I began taking my
new meds, I can even resist this huge urge to start replying to mails
from June).

In-Reply-To: <1131653507.11283.31.camel@dv>
7261 N T Nov 10 Pavel Roskin    ( 1.8K)
	Re: [PATCH] cg-pull to stop treating "master" specially,
	fix fetch_local for .git/HEAD
(deliberately quoted in entirety)

Dear diary, on Thu, Nov 10, 2005 at 09:11:47PM CET, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> On Thu, 2005-11-10 at 20:24 +0100, Petr Baudis wrote:
> >   can you still remember why did you introduce this? In GNU cp
> > documentation, I can see just
> > 
> >        -b, --backup
> >               Make backups of files that are about to be overwritten or removed.
> > 
> > which doesn't make sense to me - -L dereferences symlinks.
> 
> You are right, it must be my error.  Anyway, it was so long ago that I
> would need to review and retest it.

Is it correct that all there is to it is to check if cloning locally
works properly with symlinked HEAD in the remote repository?

> While at that, let's stop using symlinks.  git doesn't use symlinks on
> Cygwin.  I think git should use that code on all OSes, since the
> benefits of using symlinks are minimal (I think the only benefits are
> their atomicity and resolving the reference in the kernel rather than in
> userspace).  Having more uniform code for all platforms would simplify
> development and testing.  It could also reduce requirements for the
> transport protocols.  Finally, symlinks could be still used by the users
> (if they know what they are doing) - git and cogito would simply become
> symlink agnostic.
> 
> When files are copied around, symlinks are pain to deal with.  They
> require special handling to be preserved both for remote operation and
> dereferenced for local operation (that's what my patch was intended to
> do).  I'm not even considering what would happen when cloning from Linux
> to Windows or vice versa.

I personally would not mind getting rid of symlinks completely, but we
will still have to support them for some reasonable time period (several
major releases, as far as Cogito is concerned - actually, there is
plenty of people still using 0.13 and such).

If more people think this is good idea, I could even again introduce
some compatibility code to cg-Xlib which will rewrite symlinkish HEAD
when it hits it (the kind of stuff we did in the old times).

> Sure, it can wait until git 1.0, but it would be great to keep this goal
> in mind.
> 
> Disclaimer - I'm not reading the git mailing list, so if it was
> discussed, I'm sorry, I don't intend to restart that discussion - just
> give me the pointer and I'll read it.

I didn't notice such a discussion yet.

-- 
				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: Getting rid of symlinks in .git?

[Simon Richter]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

Hello,

Petr Baudis wrote:

> I personally would not mind getting rid of symlinks completely, but we
> will still have to support them for some reasonable time period (several
> major releases, as far as Cogito is concerned - actually, there is
> plenty of people still using 0.13 and such).

As someone who carries around git repositories on VFAT formatted USB 
sticks, I welcome our symlink-deprived overlords.

    Simon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

Re: Getting rid of symlinks in .git?

[Alex Riesen]

On 11/11/05, Simon Richter <Simon.Richter@hogyros.de> wrote:
> > I personally would not mind getting rid of symlinks completely, but we
> > will still have to support them for some reasonable time period (several
> > major releases, as far as Cogito is concerned - actually, there is
> > plenty of people still using 0.13 and such).
>
> As someone who carries around git repositories on VFAT formatted USB
> sticks, I welcome our symlink-deprived overlords.
>

But you shouldn't care if you have reasonably recent git everywhere:
symlinks and their absence already handled: .git/config created by
init-db contains the configuration parameter for filemode, which
decides whether it is safe to use the symlinks on the underlying
filesystem.
It looks more like a rhetorical question of code cleanup, because
in-file symlinks already handle all possible cases.

Re: Getting rid of symlinks in .git?

[Petr Baudis]

Dear diary, on Fri, Nov 11, 2005 at 01:43:18PM CET, I got a letter
where Alex Riesen <raa.lkml@gmail.com> said that...
> It looks more like a rhetorical question of code cleanup, because
> in-file symlinks already handle all possible cases.

Another example recently mentioned is detecting current branch over
HTTP, where you can't see where the HEAD's symlink heads to.

Actually, cg-fetch wouldn't handle the 'ref:' head properly. Just fixed
that.

-- 
				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: Getting rid of symlinks in .git?

[Johannes Schindelin]

Hi,

On Fri, 11 Nov 2005, Simon Richter wrote:

> As someone who carries around git repositories on VFAT formatted USB 
> sticks, I welcome our symlink-deprived overlords.

Please note that symlinks are much more performant than symrefs. Working a 
lot with switching branches, this matters.

And -- as has been mentioned elsewhere -- it is no longer a problem to 
work on filesystems which don't support symlinks using a platform which 
does.

Hth,
Dscho

Re: Getting rid of symlinks in .git?

[Petr Baudis]

  Hello,

Dear diary, on Fri, Nov 11, 2005 at 03:14:24PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Fri, 11 Nov 2005, Simon Richter wrote:
> 
> > As someone who carries around git repositories on VFAT formatted USB 
> > sticks, I welcome our symlink-deprived overlords.
> 
> Please note that symlinks are much more performant than symrefs. Working a 
> lot with switching branches, this matters.

  this is interesting. What operations get slowed down noticeably in
particular? Do you have any timing testcases and data at hand?

  Thanks,

-- 
				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: Getting rid of symlinks in .git?

[Johannes Schindelin]

Hi,

On Fri, 11 Nov 2005, Petr Baudis wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > 
> > Please note that symlinks are much more performant than symrefs. Working a 
> > lot with switching branches, this matters.
> 
> What operations get slowed down noticeably in particular?

Well, if you have to read two files instead of one, it is 100% slower ;-)

> Do you have any timing testcases and data at hand?

No and no.

Note that the only symlink/symref you usually have is .git/HEAD. But it 
feels wrong to take the worse approach in *all* cases, just because 
*one* brain-fscked file system/operating system does not support the 
superior approach.

Conclusion: I can live with the symref support in git "AS IS".

Ciao,
Dscho

Re: Getting rid of symlinks in .git?

[Petr Baudis]

Dear diary, on Fri, Nov 11, 2005 at 04:40:43PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Fri, 11 Nov 2005, Petr Baudis wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > > 
> > > Please note that symlinks are much more performant than symrefs. Working a 
> > > lot with switching branches, this matters.
> > 
> > What operations get slowed down noticeably in particular?
> 
> Well, if you have to read two files instead of one, it is 100% slower ;-)

But you usually don't read the HEAD that often...

Besides, the kernel has to read the symlink file as well in order to
follow the symlink. ;-)

> Note that the only symlink/symref you usually have is .git/HEAD. But it 
> feels wrong to take the worse approach in *all* cases, just because 
> *one* brain-fscked file system/operating system does not support the 
> superior approach.

This is about being consistent, and also to support dumber protocols
better.

-- 
				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: Getting rid of symlinks in .git?

[Nick Hengeveld]

On Fri, Nov 11, 2005 at 04:40:43PM +0100, Johannes Schindelin wrote:

> Note that the only symlink/symref you usually have is .git/HEAD. But it 
> feels wrong to take the worse approach in *all* cases, just because 
> *one* brain-fscked file system/operating system does not support the 
> superior approach.

Symlinks at the other end of an HTTP transport are also similarly
brain-challenged.

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

Re: Getting rid of symlinks in .git?

[Johannes Schindelin]

Hi,

On Fri, 11 Nov 2005, Petr Baudis wrote:

> This is about being consistent, and also to support dumber protocols
> better.

For my local development, I couldn't care less about dumber protocols.

Hth,
Dscho

Re: Getting rid of symlinks in .git?

[Alex Riesen]

Simon Richter, Fri, Nov 11, 2005 13:55:14 +0100:
> >But you shouldn't care if you have reasonably recent git everywhere:
> >symlinks and their absence already handled:
> 
> Well, I don't have working directories on USB sticks, so I don't 
> actually use the symlinks, would they be there, but I'm definitely 
> annoyed by not being able to copy a .git directory from some project 
> over and be done with it.
> 

Reasonable, perhaps. But are the git-pull and -clone _that_ slow or
awkward? Besides, you'd probably end up copying more than you'd want.

That's interesting case, btw. I'm restoring git mailing list in cc, so
it gets a bit wider of auditorium.

Re: Getting rid of symlinks in .git?

[Junio C Hamano]

Alex Riesen <raa.lkml@gmail.com> writes:

> But you shouldn't care if you have reasonably recent git everywhere:
> symlinks and their absence already handled: .git/config created by
> init-db contains the configuration parameter for filemode, which
> decides whether it is safe to use the symlinks on the underlying
> filesystem.

No, no no nononononono....

core.filemode is whether the executable bit is trustworthy and
does not have anything to do with symlinked heads, although
these two happen to become problematic on VFAT.

Currently we have USE_SYMLINK_HEAD and have failing symlink()
call fall back on regular file symrefs.

But this may not matter as long as nobody would want to force
regular file symrefs on a filesystem that is capable of doing a
symlink.  That is the only thing we cannot do right now.

Re: Getting rid of symlinks in .git?

[Alex Riesen]

On 11/15/05, Junio C Hamano <junkio@cox.net> wrote:
> > But you shouldn't care if you have reasonably recent git everywhere:
> > symlinks and their absence already handled: .git/config created by
> > init-db contains the configuration parameter for filemode, which
> > decides whether it is safe to use the symlinks on the underlying
> > filesystem.
>
> No, no no nononononono....
>
> core.filemode is whether the executable bit is trustworthy and
> does not have anything to do with symlinked heads, although
> these two happen to become problematic on VFAT.

Of course! Silly me...