git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Petr Baudis <pasky@suse.cz>, Junio C Hamano <junkio@cox.net>,
	git@vger.kernel.org
Subject: Re: [PATCH] Disable USE_SYMLINK_HEAD by default
Date: Tue, 15 Nov 2005 11:50:36 -0500	[thread overview]
Message-ID: <1132073436.25640.32.camel@dv> (raw)
In-Reply-To: <Pine.LNX.4.63.0511151518210.23020@wbgn013.biozentrum.uni-wuerzburg.de>

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

  parent reply	other threads:[~2005-11-15 16:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-15  5:59 [PATCH] Disable USE_SYMLINK_HEAD by default Pavel Roskin
2005-11-15  7:03 ` Junio C Hamano
2005-11-15  8:13   ` Pavel Roskin
2005-11-15  8:24     ` Junio C Hamano
2005-11-15 10:24       ` Junio C Hamano
2005-11-15 11:09         ` Johannes Schindelin
2005-11-15 12:18           ` Petr Baudis
2005-11-15 14:24             ` Johannes Schindelin
2005-11-15 15:37               ` Adrien Beau
2005-11-15 16:50               ` Pavel Roskin [this message]
2005-11-15 17:05             ` Junio C Hamano
2005-11-15 17:21               ` Pavel Roskin
2005-11-15 17:32                 ` Nick Hengeveld
2005-11-15 17:33                 ` Linus Torvalds
2005-11-15 17:42                   ` Petr Baudis
2005-11-15 18:01                     ` Linus Torvalds
2005-11-15 18:13                 ` Junio C Hamano
2005-11-15 17:06             ` Pavel Roskin
2005-11-15 18:21               ` Junio C Hamano
2005-11-16  1:56                 ` Pavel Roskin
2005-11-16  3:13                   ` Junio C Hamano
2005-11-16  1:05             ` Josef Weidendorfer
2005-11-15 10:31     ` Catalin Marinas
2005-11-15 16:27       ` Pavel Roskin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1132073436.25640.32.camel@dv \
    --to=proski@gnu.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=pasky@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).