Re: [PATCH 3/3] Teach "git branch" about --new-workdir

From: Marius Storm-Olsen <marius@trolltech.com>
Date: Jul 24, 2007, 11:14 UTC
Message-ID: <46A5DF1F.2030307@trolltech.com>
In-Reply-To: <7vd4yigmla.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano said the following on 24.07.2007 11:47:

Show 11 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>> While you guys are discussing this, please please keep in mind
>>> that there are Windows users (/me raises his hand) out there
>>> that really really want this too. So, please try to keep it
>>> light on the symlinks.
>> Easy: use cygwin.
>> 
>> Okay, a bit more seriously again: in the recent weeks, it seems
>> that more and more Windows users are asking for features.  Since
>> I guess you are a developer (why else would you want to use git),
>> IMHO it is your itch to scratch.

Yes, I fully agree with this, and I don't have the attitude that others should work for me. I'm trying to free up some 'spare time' resources so I can pitch in on the effort of making Git work neatly on Windows. However, I feared I won't be able to get working on it before you guys had decided on a design, so I just wanted voice my opinion on the design, so Windows users are not lost in this.

Show 6 quoted lines

> 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*)

I think you're right in that this is probably not the appropriate itch to scratch for a Windows developer to start with, and I have my own list of issues to work on when I get the time. File stat'ing (daemon/service), CRLF issues, de-SH'ifying commands, non-MinGW native build of Git, etc.. Lots to keep my fingers busy :-)

Though, let me also say that I already love working with Git on Windows. And I thank each and every one who's working on it, for providing such an excellent tool.

-- 
.marius