I have installed cygwin on a windows server, solely for use of ssh.
In addition, I've installed Git for Windows, having discounted the use of Cygwin git as it doesn't support the windows extensions.
I have a git ssh user which can login (via ssh) and can create the repositories under this user's home directory. This allows me to push to the server from OSX running SourceTree. In this case, the repository is located with: -
git#GitServer:Repos/Project.git
The actual path to the folder under cygwin is: -
/cygwin/home/git/Repos/Project.git
However, I want to be able to have the Repos directory placed directly at the root of the cygwin folder, not under a home folder: -
/Repos/Project.git
Doing this causes SourceTree to fail when trying to push to the repo. I'm defining the path like this: -
git#GitServer:/Repos/Project.git
I have also checked permissions on the folders and this is not the issue.
The failure results in this message: -
fatal: '/Repos/Project.git' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I can understand that I'd have problems if the repo was placed outside of the cygwin folder, but should it not be possible for it to be placed at the root and can anyone explain how I can get the SourceTree path to access the repo, if it's placed at the root, without having to create symbolic links?
So you have a directory with Git repositories placed in the Cygwin's root directory. I will expect, that your Cygwin's root directory is c:\cygwin, so directory with the Git repository is c:\cygwin\Repos\Project.git. Cygwin's root directory is mounted as / in Cygwin, so your Git repository directory is /Repos/Project.git.
SourceTree is native Windows .NET application, so it uses Windows file system and Windows style paths. Therefore if you said SourceTree to look for Git repository in /Repos/Project.git, it was trying to find it in c:\Repos\Project.git, which is obviously wrong. Just set it to proper Windows path in SourceTree and it will work.
It's the same for any Windows application. Cygwin's path is understood only by Cygwin applications. You can use cygpath to convert Cygwin paths to Windows and vice versa. This command for example opens current directory in Cygwin in Windows Explorer:
explorer `cygpath -wa .`
Also repository can be placed anywhere you want of course, it doesn't have to be under Cygwin's root directory. It can be even on a different drive. Cygwin mounts all Windows drives as /cygdrive/<drive-letter> automatically by default, so e.g. d:\Repos is accessible as /cygdrive/d/Repos in Cygwin. You can also create a symbolic link to any directory outside of Cygwin, so you can have e.g. /cygdrive/d/Repos linked as ~/Repos for faster access from Cygwin.
Just one simple rule: under Cygwin use Cygwin style paths, under Windows use Windows style paths.
Related
When I run the WSL bash shell, I can use the "ln -s" command to create a symlink. No matter if I am working on an NTFS file system or on the WSL file system, the symbolic link gets created as expected. Specifically, the link in the WSL file system works just like a Linux symlink and the symlink in the NTFS file system is a Windows symlink and I can use it both from WSL and Windows.
Contrast that to how symlinks work in the Linux version of git running in WSL. I clone a repo that contains symlinks to the NTFS file system. I am not sure what the links are, but they are most definitely not Windows symlinks.
Some might say that I should use the Git for Windows which creates the proper Windows symlink when I clone the repo. The only issue is that we have tools written as bash scripts that everyone uses and these tools call git. They work fine on Linux but from WSL they do not perform as expected because of the symlink issue. I have found that I need all the command-line developer tools to run in WSL so that they can call each other and pass file paths and env vars and such. So it is really not an option for me to run Git for Windows.
Is there any means to get this addressed? If the WSL bash shell can function properly then surely a small change in the Linux version of git could also fix this issue. This smells of some sort of philosophical fight between Windows and Linux. Or is there a legacy to this that pre-dates Git for Windows... In which case, surely there is a way to enable a new treatment of symlinks for those who want to use Windows symlinks.
This is likely an issue in Windows and the Windows Subsystem for Linux.
The emulated Linux environment creates symlinks using the symlink(2) system call, much like the ln -s command does.
The reason this is tricky to support is because Windows symlinks are less capable than Unix symlinks. Unix symlinks can point to any location, regardless of the object at that location, and the destination need not exist. Windows symlinks, on the other hand, point to either a file or a directory, but are pinned to one type.
The standard Git, as shipped by upstream, checks to see if symlinks can be created pointing to a file that does not exist. That this works is important because Git need not check out the destination file before the symlink. If this fails, Git sets core.symlinks to false, and what's written instead are files with the contents of the symlinks. WSL can't create a symlink of the right type when this test occurs (because there's no destination), and consequently, the operation fails.
Git for Windows likely has some functionality to work around this issue with symlinks in Windows. It also has a huge number of patches which are not included in the version shipped by upstream, and hence not the version used by most Linux distros.
I should point out that there's a Linux distro that also shipped a patch that permitted symlinks to be created only if they pointed to a file the user (and not anyone else) owned, and it broke things in the same way.
You can try to run git config core.symlinks true in a fresh repository and see if that works as you expect; it may, or it may not. If it doesn't, you can see if the Git for Windows maintainer will send the patch they're using upstream, and it may eventually be included in a newer version of Git, and hence in a newer version of Linux distros. However, because Linux distros typically provide stable versions, this will take time, usually on the order of years, unless you pull down a newer package.
In general, though, you can't expect Unix code to work adequately on an NTFS file system because it's fundamentally different, and Microsoft even documents this behavior. Microsoft knew (or should have known) when they added symlinks how Unix symlinks functioned, and for some reason they chose to do it differently. I personally think that was a mistake, and here we are now.
Yesterday I started using Git to version control documents I'm working on. I use two systems, a Windows 10 desktop, and a MacBook Air. I save the documents to a directory on the internet, think Dropbox.
I configured Git to use the internet directory for Windows 10. Is it also possible to use this same directory for Git on my Mac? Or do I instruct my Git on the Mac to use a different directory on the Mac?
Git Mac: 2.15.1 (No manual entry for gitwork-tree)
Git Windows 10: 2.16.2.windows.1
Every version control system maintains the directory name of the local folder the same name as the repository (Source Folder). Then if you clone your project from git repository ( git clone https://github.com/myaccount/my-project ) the diretory name in any Operating System will be the same of the repository "my-project".
I want to install Git for Windows on my working machine. The problem is I don't have the necessary permissions in Program Files and noone will grant me these (company policy). Is there any workaround?
Use this version:
Git Portable
https://github.com/sheabunge/GitPortable
Git Portable is a portable version of Git for Windows packaged in PortableApps.com Format.
# ... Copy the GitPortable directory from this repository to a location of your choice.
I have installed Windows 10 x64 on my laptop, and then go with latest Git as well (Git-2.6.3-64-bit). As I see on my laptop, Git now is installed at this directory: C:\Users\MyPC\AppData\Local\Programs\Git (I have no chance to specify another particular folder because it's done automatically during Git installation). The options "Use Git from the Windows Command Prompt" and "Use OpenSSH" are already selected, the windows path is updated with Git dir. And after all, the problem is, Windows cannot recognize where Git is to call. I've tried git --version but it's unrecognized from Windows.
My questions are (on Windows 10 Pro x64):
1. Can we specify another installation folder for Git?
2. In Git dir/bin, there no ssh.exe, while in OpenSSH selection dialog, it tells me "This uses ssh.exe that comes with Git". So where is it, the built-tin SSH client?
3. I'm doubting that now Windows 10 doesn't accept any external program installed on %USERPROFILE%/AppData to be included to system path. Is it correct?
4. How to make Windows "see" Git?
Just solved this myself this was a very frustrating journey but for me the following got me going:
Make sure c:\Windows\System32\OpenSSH\ is in your path variables (yea I know Windows should see this on its own)
Go to C:\Users\<>.gitconfig edit your global git config file to point to the correct ssh.exe 'C:/Windows/System32/OpenSSH
Make sure your id_rsa.ppk file is in C:\Users\<>.ssh If you don't have an SSH key yet generate one and make sure it ends up in this folder
You may also want to check that your OpenSSH Authentication Agent is started in Windows Services
Can we specify another installation folder for Git?
Try running the installer as an administrator, so it can be installed to Program Files. I'm not sure how to specify a custom path.
In Git dir/bin, there no ssh.exe, while in OpenSSH selection dialog, it tells me "This uses ssh.exe that comes with Git". So where is it, the built-tin SSH client?
Some digging told me that it might live inside the .ssh folder in the Git installation, so C:\Users\MyPC\AppData\Local\Programs\Git\.ssh
I'm doubting that now Windows 10 doesn't accept any external program installed on %USERPROFILE%/AppData to be included to system path. Is it correct?
AFAIK you can add any directory to your path.
How to make Windows "see" Git?
Add C:\Users\MyPC\AppData\Local\Programs\Git to your path:
Start the System Control Panel applet (Start - Settings - Control Panel - System).
Select the Advanced tab.
Click the Environment Variables button.
Under System Variables, select Path, then click Edit.
You'll see a list of folders, as this example for my system shows: C:\Program Files\Windows Resource Kits\Tools\;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files\Support Tools\;C:\Program Files\Common Files\Roxio Shared\DLLShared;C:\Program Files\Common Files\Ulead Systems\MPEG;C:\Program Files\Intel\DMIX;C:\Program Files\Executive Software\Diskeeper\;C:\Program Files\Bonjour\;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Misc
You can add additional folders that you want to include in searches. I add a "C:\program files\misc" entry into which I place my standalone utilities, instead of copying them into C:\windows. Click OK.
You'll need to restart the processes (e.g., command prompt) that use the system path to see the added folders.
From http://windowsitpro.com/systems-management/how-can-i-add-new-folder-my-system-path
I want to be able to sync a work repo from my Windows 7 desktop to my Windows 7 laptop without pushing my commits to our main server. How do I do this? I can't figure out how to set up a remote path so that git can understand where it is. I generally use Git Bash for dealing with git, not the windows commandline, so the issue here is likely that I can't figure out how to write a path in Git Bash which will reference a windows share.
So, say I have a repo at (windows share path):
\\\\MyWorkPCName\dev\myrepo\
And in the command line, I can access the directories and files (albeit using pushd since cmd is stupid), how do I convert this in to a valid git remote?
While Git doesn't recognize backslashes, Windows does recognize forward slashes:
git remote add desktop //MyWorkPCName/dev/myrepo
Git Bash also lets you access windows drives using UNIX-style paths, e.g. C:\Users\bug\repo becomes /c/Users/bug/repo.