From: Marius Storm-Olsen <marius@trolltech.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Git Mailing List <git@vger.kernel.org>,
msysGit <msysgit@googlegroups.com>
Subject: Re: '.git file' alternative, native (cross-platform) workdir support.
Date: Fri, 29 Feb 2008 15:51:52 +0100 [thread overview]
Message-ID: <47C81C08.2060608@trolltech.com> (raw)
In-Reply-To: <alpine.LSU.1.00.0802291333310.22527@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]
Johannes Schindelin said the following on 29.02.2008 15:25:
> On Fri, 29 Feb 2008, Marius Storm-Olsen wrote:
>> I'm actually not sure that it's impossible to make it safe. My
>> implementation works by redirecting files into the real repo.
>> However, we can also detect when redirection is in effect, and do
>> extra 'maintainance' things then, to avoid the bad effects.
>
> From the perspective of Windows, I guess it is easy to overlook the
> fact that permissions can break your idea.
>
> Even after creating a second working tree for an existing
> repository, the permissions of the original repository can change.
Sure, but that would break _any_ working tree implementation. Without
access to the original data, it whole thing is bust, no matter if you
redirect all or part of .git/.
Checking if we have access to the redirected .git is trivial in both
cases. (partial or whole redirection)
> The only way to be on the safe side is to use _the repository_
> twice. IOW not having a second .git/ directory.
>
> Also, having a single .git is just a very simple, and thus
> preferable concept, to having part of this, and part of that
> repository.
I whole heartedly agree. I'm not proposing to keep it split in the
long run. I'm just proposing something that 'works' *now*, and can be
improved incrementally; as opposed to, doesn't work now, and needs to
be fully implemented before it works for the Windows crowd.
PS. The redirection method I propose already alleviates an issue of
the current git-new-workdir has, which Shawn has experienced many
atime: The deletion of .git/config and .git/packed-refs, making
'git-config' and 'git tag -d' unsafe in a workdir. (Though I'm unsure
if that has been fixed already. In any case, since the files are
really redirected, there no chance that deleting a file will remove a
synlink, only to be recreated as a normal file instead)
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
next prev parent reply other threads:[~2008-02-29 14:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-29 12:27 '.git file' alternative, native (cross-platform) workdir support Marius Storm-Olsen
2008-02-29 12:54 ` Johannes Schindelin
2008-02-29 13:24 ` Marius Storm-Olsen
2008-02-29 14:14 ` Jakub Narebski
2008-02-29 14:25 ` Johannes Schindelin
2008-02-29 14:51 ` Marius Storm-Olsen [this message]
2008-02-29 20:02 ` Junio C Hamano
2008-02-29 21:32 ` Marius Storm-Olsen
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=47C81C08.2060608@trolltech.com \
--to=marius@trolltech.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=msysgit@googlegroups.com \
/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.