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

[Marius Storm-Olsen <marius@trolltech.com>]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

Junio C Hamano said the following on 24.07.2007 11:47:
> 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.


> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]