From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: [PATCH 3/3] Teach "git branch" about --new-workdir
Date: Wed, 25 Jul 2007 02:09:46 +0200 [thread overview]
Message-ID: <f864c6$bg5$1@sea.gmane.org> (raw)
In-Reply-To: Pine.LNX.4.64.0707241252040.28577@reaper.quantumfyre.co.uk
Julian Phillips wrote:
> On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:
>
>>> I do not know this is an appropriate itch to scratch for a Windows
>>> developer to begin with. The new-workdir setting *is* about
>>> symlinked .git/ metainfo space. If somebody wants to work on a
>>> filesystem without symlink, he should not be using new-workdir but
>>> something else. E.g. GIT_DIR + GIT_WORK_TREE, or perhaps GIT_DIR +
>>> core.worktree comes to mind.
>>
>> That's is definitely an option, though it seems to me that its more like
>> giving up than a finding a proper solution. In any case, it would result in
>> two completely different workflows on systems with and without symlink
>> support. I work on both, and would like my workflow to be consistent. Of
>> course I could easily add my own scripts on top to achieve this, but then
>> we're going back into h4x0r land and not making Git more 'available'.
>>
>> The new-workdir feature doesn't *have* to be about symlinked .git/ metainfo
>> space, but could also be about symref'ed .git/ metainfo.
>> (A discussion was done in 2005s "Getting rid of symlinks in .git?", but the
>> conclusion was that it would slow it down too much? *ponder*)
>
> Symref'ed isn't really the right term ... we're not talking about refs
> here. You would have to basically implement symlinks _inside_ git ...
>
> New-workdir really _is_ all about symlinks. It already exists as a
> contrib feature - and moving it into core is (as I understand it) really
> just moving it, not redesigning.
>
> If you were going to avoid symlinks, then probably the cleanest way would
> be to have an explict way to point at the actual repo - rather than making
> the working look like a repo if you squint hard enough. Which sounds
> rather like it would be an extension to GIT_DIR + GIT_WORK_TREE. I
> haven't looked at it, but it shouldn't be too hard to have a mechanism
> that automatically does GIT_DIR=<there> GIT_WORK_TREE==<here> when the
> appropriate setup is in place? Though you would have to get it into all
> the appropriate places ...
I think it could be best solved by having in "worktree" .git/config with
core.gitdir which functions like lower layer in UnionFS like manner. It
means that if git cannot find a file or directory in .git, then it tries
to find it in core.gitdir.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
next prev parent reply other threads:[~2007-07-25 0:10 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-22 18:56 [PATCH 3/3] Teach "git branch" about --new-workdir Johannes Schindelin
2007-07-22 19:16 ` Daniel Barkalow
2007-07-22 19:24 ` Johannes Schindelin
2007-07-22 21:09 ` Julian Phillips
2007-07-22 21:25 ` Johannes Schindelin
2007-07-22 21:50 ` Julian Phillips
2007-07-22 21:59 ` Johannes Schindelin
2007-07-22 22:24 ` Julian Phillips
2007-07-22 22:46 ` Jakub Narebski
2007-07-22 23:37 ` Johannes Schindelin
2007-07-22 23:02 ` Johannes Schindelin
2007-07-23 3:56 ` Shawn O. Pearce
2007-07-23 4:45 ` Junio C Hamano
2007-07-23 5:14 ` Shawn O. Pearce
2007-07-23 5:22 ` Shawn O. Pearce
2007-07-23 10:32 ` Johannes Schindelin
2007-07-23 10:42 ` Johannes Schindelin
2007-07-24 8:19 ` Marius Storm-Olsen
2007-07-24 9:02 ` Johannes Schindelin
2007-07-24 9:47 ` Junio C Hamano
2007-07-24 11:07 ` Johannes Schindelin
2007-07-24 11:14 ` Marius Storm-Olsen
2007-07-24 12:06 ` Julian Phillips
2007-07-24 12:28 ` Marius Storm-Olsen
2007-07-24 12:37 ` Johannes Schindelin
2007-07-24 13:47 ` Josef Weidendorfer
2007-07-24 13:54 ` Johannes Schindelin
2007-07-24 14:21 ` Josef Weidendorfer
2007-07-25 0:09 ` Jakub Narebski [this message]
2007-07-24 12:42 ` Johannes Schindelin
2007-07-24 13:26 ` Marius Storm-Olsen
2007-07-24 13:29 ` Marius Storm-Olsen
2007-07-24 13:33 ` Johannes Schindelin
2007-07-24 18:02 ` Marius Storm-Olsen
2007-07-24 18:30 ` Johannes Schindelin
2007-07-24 19:36 ` Marius Storm-Olsen
2007-07-24 23:15 ` Alex Riesen
2007-07-25 6:47 ` Marius Storm-Olsen
2007-07-25 9:39 ` Johannes Schindelin
2007-07-25 10:22 ` Steven Grimm
2007-07-25 11:05 ` Andy Parkins
2007-07-25 12:10 ` Marius Storm-Olsen
2007-07-25 14:09 ` Johannes Schindelin
2007-07-25 20:40 ` Linus Torvalds
2007-07-26 11:51 ` Christian MICHON
2007-07-23 8:31 ` Julian Phillips
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='f864c6$bg5$1@sea.gmane.org' \
--to=jnareb@gmail.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 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).