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 14:24:22 +0100 [thread overview]
Message-ID: <47C80786.4070701@trolltech.com> (raw)
In-Reply-To: <alpine.LSU.1.00.0802291248510.22527@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]
Johannes Schindelin said the following on 29.02.2008 13:54:
> On Fri, 29 Feb 2008, Marius Storm-Olsen wrote:
>> However, wouldn't simply redirecting everything into a real repo
>> then create problems with shared index file and more? A problem
>> which could be tacled by file suffixes or other methods, I'm
>> sure, but which would require even more patches to achieve the
>> goal.
>
> Not only would it requre these patches, but it would actually make
> a _safe_ multiple-workdirs feature possible.
>
> ATM the problem is that you can change a ref that is checked out
> elsewhere, and if you are not a Git expert, it will just make your
> life miserable.
>
> However, if we do not pretend to have different repositories, but
> actually use the _identical_ repository for multiple working
> directories, we can make the mechanisms safe!
>
> This is basically the reason why I do not like the current
> new-workdir script (and the patch in my private tree where I taught
> git-branch about it).
>
> So while your approach may seem easier in the short run, there is
> no way you can make it safe. No way, except going the full nine
> yards, and actually use the same repository, which means that you
> have to have the "other patches", too.
Sure, I'm aware of that. The initial goal was to make something which
works as the current contrib/workdir/git-new-workdir, just
cross-platform. Then we can take it from there, step by step, until we
have something which works safely; instead of taking a single big leap.
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.
For example, when setting up a workdir, we could duplicate
<real repo>/.git/refs/*
into <real repo>/.git/refs/workdir-<sha1>/*
(<sha1> being the sha1 of the abs path to the workdir)
and have the redirection mechanism redirect all git_path("refs/*") to
the duplicated locations. That way, when pulling in the workdir, it
wouldn't create havok with the real repo's refs. Then in the real
repo, you can easily refer to the refs in from the workdir too, when
you need to.
There are several possibilities here. Since file redirection works
from the beginning, we have a place to start, which can slowly migrate
into whatever. When you think about it, my approach is kinda similar
to the '.git file' approach, just that I don't redirect everything
from the start, just parts to make it work as today on Linux. In the
end my technique could also redirect everything into the real repo,
giving you the same effect as the '.git file'.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
next prev parent reply other threads:[~2008-02-29 13:25 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 [this message]
2008-02-29 14:14 ` Jakub Narebski
2008-02-29 14:25 ` Johannes Schindelin
2008-02-29 14:51 ` Marius Storm-Olsen
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=47C80786.4070701@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 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).