git-new-workdir

[Jörg Rosenkranz]

Hi all,

I have done a port of git-new-workdir to run on Windows. The CMD can
be found at github:
https://github.com/joero74/git-new-workdir/blob/master/git-new-workdir.cmd

The port was tested on Windows 7. Maybe its usefull for anyone.

Joerg.

[Joshua Jensen]

I am interested in this, but I don't understand why it was converted
from the shell script to a Windows batch file. mklink is easily run
from the shell script, too, and then it could be nearly identical to
contrib/ Git version.

-Josh

[Jörg Rosenkranz]

2011/3/24 Joshua Jensen <jje...@workspacewhiz.com>

I am interested in this, but I don't understand why it was converted from the shell script to a Windows batch file.  mklink is easily run from the shell script, too, and then it could be nearly identical to contrib/ Git version.

You're maybe right. I did this port as I'm working in the CMD almost exclusively.

Joerg.

[dansm...@gmail.com]

I predominately use Git Bash on Windows, so I modified the script like you suggested.  It works on Windows Vista, but hasn't been tested in other environments.

https://github.com/dansmith65/git/blob/master/contrib/workdir/git-new-workdir-win

[Johannes Schindelin]

Hi Dan,

On Tue, 14 Jun 2011, dansm...@gmail.com wrote:

> I predominately use Git Bash on Windows, so I modified the script like
> you suggested.

Just out of curiosity: who exactly did you refer to by "you"? You neither
addressed somebody in particular, nor did you Cc: anybody except for the
list.

Just asking,
Johannes

[dansm...@gmail.com]

(sorry, I hardly use Google groups, and may have misunderstood how it works)

This was the post I was referring to: https://groups.google.com/d/msg/msysgit/1z07lWg9Nts/kb-bMt2fZsQJ

I clicked "Post reply", and assumed it would be threaded and reference the original post; which it seems to do when viewing via groups.google.com, but I guess it doesn't reference the original post in emails.

By "you", I meant Josh Jensen, the author of the post I linked to above.

[Marius Storm-Olsen]

dansm...@gmail.com said the following on 14.06.2011 23:07:

Shouldn't simply the already existing git-new-workdir be altered to
check for OS type, and do the right thing when on Windows?

Also, the script is using symbolic links on Windows, which per
definition is correct. However, creating symbolic links requires
Administator privileges, and will fail if you don't run under a
CMD/Bash which has the Administrator rights assigned (not default,
even when logged in as an Administrator).

Probably it would be better to use hardlinks on Windows (/H option to
mklink), since that does *not* require Administrator privileges. Most
users won't notice the difference anyways.

--
.marius

[Daniel Smith]

Good call on both accounts; I think your idea is how it should be
implemented. I'm not sure if i'll get around to doing myself though;
since it works for me as-is.

- Dan

[Jörg Rosenkranz]

2011/6/19 Marius Storm-Olsen <mst...@gmail.com>

Probably it would be better to use hardlinks on Windows (/H option to mklink), since that does *not* require Administrator privileges. Most users won't notice the difference anyways.

I've tried that in the first step if I remember correctly. Some tool (Explorer?) then shreddered my main repository when I deleted the new work dir.I think, it went recursively into the folders without paying attention to the links. I will test this again if I find some time.

Joerg.

[matt.d....@gmail.com]

Thanks Dan. Your Windows port worked well for us.

Matt

CRTech

Boulder, CO

[sun]

Hi all,

Thanks for bringing up this topic.  The git-new-workdir script definitely is a power tool that is a major enabler for custom (but natural) development workflows.

Unfortunately, the proposed solution of embedding Windows support into the existing *nix shell script did not work in my environment, whereas my environment is most likely a bit special, but nevertheless I expected it to work.  After studying various public posts and MS docs, it is actually of vast importance to state what exactly the environment conditions are, so for the sake of completeness:

1. UAC is enabled, and the current user has Administrator privileges.  This causes mklink to not work without privilege escalation.
2. Both Cygwin and msysgit/mingw32 (via TortoiseGit) are installed, and both participate in %PATH%, whereas Cygwin has precedence.

In order to run the script in an UAC-enabled environment (as a Windows user with administrative privileges), you have to use `runas`:

  runas /env /user:administrator "mklink target source"

or to be more on-topic here:

  runas /env /user:administrator "git-new-workdir path/to/repo path/to/new/workdir"

Note: The paths used in this example do not work as presented, because this command line has to be invoked from a Windows command shell, but the combined/embedded script does not contain logic to convert *nix paths into Windows paths, so `mklink` receives pathnames that it cannot interpret.  At the same time, the rest of the script expects *nix paths.  I'm not sure how the proposed script by +Daniel Smith can reasonably work.

After fixing that, the combined/embedded script did manage to create symlinks, but in all possible environments available to me, the symlinks (as well as all files in the working directory checkout) were effectively owned by no one, and not even Administrators had write access.  I tried native Cygwin bash and sh, as well as the mingw32/msysgit bash.  My environment is definitely prepared for cross-environment interactions, I did not experience this symptom since ~2005 (back then, caused by a missing `set CYGWIN=nontsec`).

Researching and debugging further, that problem appears to stem from the necessary `runas` process invocation call chain, which essentially turns into this:

runas → cmd → cygwin/mingw32/msysgit → bash → cmd → mklink

The runas user context seems to get lost in the (ba)sh script execution context.  I can only assume that there's just simply a limit of Windows user and security context persistence that can reasonably be expected from ports like msysgit/mingw32 and cygwin. ;-)

In order to resolve this issue and make git-new-workdir available for Windows, I ultimately resorted to +Jörg Rosenkranz's original approach of porting the script into a native .cmd script:

https://github.com/git/git/pull/87

However, in order to facilitate ongoing maintenance of the two scripts, I essentially restarted from scratch and re-implemented the bash script 1:1 as batch script, including structure, comments, code, and execution flow.  I took over some code from Jörg, but mostly replaced his code with simpler alternatives in order to mirror the existing script.

Let me know what you think,
sun