Re: '.git file' alternative, native (cross-platform) workdir support.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux