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 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.