From: Jakub Narebski <jnareb@gmail.com>
To: "Patrick Higgins" <Patrick.Higgins@cexp.com>
Cc: git@vger.kernel.org
Subject: Re: Windows symlinks
Date: Tue, 24 Jun 2008 16:28:22 -0700 (PDT) [thread overview]
Message-ID: <m3od5qjtv1.fsf@localhost.localdomain> (raw)
In-Reply-To: <911589C97062424796D53B625CEC0025E4618F@USCOBRMFA-SE-70.northamerica.cexp.com>
Patrick Higgins <Patrick.Higgins@cexp.com> writes:
> It looks like one of the bigger (biggest?) hurdles for git adoption
> at my company is going to be handling symlinks on Windows. We may be
> able to sidestep the issue [...] by [...] run[ning] Linux
> in a virtual machine [...]
If only MS Windows supported other filesystems which have symlinks...
> Has anyone thought about a way for git to handle symlinks? Vista
> seems to have added native symlinks, but you need have elevated
> privilege to create them. NTFS junction points seem helpful for
> older versions of Windows, but don't work for anything except
> directories, and seem to be dangerous to use with tools that do
> recursive deletes. Neither junction points nor native symlinks sound
> like great options.
>
> Cygwin's clever symlink trick seems to work pretty well in
> practice. I'm not exactly sure what it's doing, but it seems to
> create a shortcut that it's own programs understand. Some other
> non-Cygwin programs seem to understand them, too, but Java does not
> which is a big problem for me.
First, I think that both "git on Windows" solutions, namely Cygwin and
msysGit port, don't use symlinks either in installed programs, nor in
repository layout.
Second, the problem there can be _only_ if your repository contains
(or contained) symlinks, and then it is your own damn fault. I don't
know how Cygwin, or msysGit deals with symlinks in a wirking
directory, but you can work around symlinks (although in a bit
unwieldy way) by using `core.symlinks' configuration variable;
see git-config(1):
core.symlinks::
If false, symbolic links are checked out as small plain files
that contain the link text. git-update-index(1) and git-add(1)
will not change the recorded type to regular file. Useful on
filesystems like FAT that do not support symbolic links. True
by default.
--
Jakub Narebski
Poland
ShadeHawk on #git
next prev parent reply other threads:[~2008-06-24 23:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-24 22:42 Windows symlinks Patrick.Higgins
2008-06-24 23:18 ` Avery Pennarun
2008-06-26 3:50 ` Jay Soffian
2008-06-24 23:28 ` Jakub Narebski [this message]
2008-06-24 23:42 ` Patrick.Higgins
2008-06-25 0:04 ` Avery Pennarun
2008-06-25 17:50 ` Patrick.Higgins
2008-06-26 6:33 ` Andreas Ericsson
2008-06-24 23:29 ` Robin Rosenberg
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=m3od5qjtv1.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=Patrick.Higgins@cexp.com \
--cc=git@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.