Petr BaudisI'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...
Show 11 quoted lines
> 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?
Show 15 quoted lines
> 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).
Show 6 quoted lines
> 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.
