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.
Related
On my Windows machine, I have a repository that works nicely with msysgit. But when I try running git status on cygwin, it just hangs, without printing anything until I press Ctrl-C.
How can I investigate this to find out the reason for such behaviour?
The reason for this was the difference in core.autocrlf setting. When install git for windows, I set it to automatically convert line endings in both directions, so the files in the filesystem were actually different from the files saved in git history - but windows git always hid these differences.
Meanwhile, cygwin git was working extremely slow because it detected differences in every line of thousands of text files in my repository.
I'm working in a large corporate enterprise where all the developer machines are Windows 7 Enterprise SP1.
I'm running major migration project from RTC to git (resulting in something like 1200 git repos). There are no Windows servers in the production environment, build or test environments - everything is either Solaris or RedHat. The solution will be rolled out to ~200 developers.
There is generally a push to use more Unix-command line tools and there are a few different alternatives on Windows such as: Cygwin, git-bash, cmder. I have avoided running a full linux VM because that introduces too many other problems (most developers don't have local admin rights and the internet proxy is a constant hassle so I don't want to make networking a bigger problem with NAT).
I've been running Cygwin (mintty 2.6.2) for the past 8 months and it's been ok until today where I hit a very concerning issue with git (v2.8.3) where git status reported a clean working directory even though multiple files and folders had been deleted in the repo. Only after I recreated a folder with the same name as one of the deleted folders did all the deleted files appear correctly with git status.
I'll explain the symptoms and what I was doing but so far I have not reproduced the issue. My suspicion is that the problem lays somewhere between the emulated linux file system and the actual windows file system. Is there any difference in the way the various emulators achieve this?
The specific problem I hit had these symptoms:
Client side:
git status showed a clean working directory
git log showed 3 commits A, B and C (commit C checked out)
The repo contents was one folder containing a file, 2 more files in the root folder, plus the .git folder with contents
git stash list was empty
git branch -a reports only master, HEAD and origin/master
Server side:
The origin contained 13 additional folders, each with one file
The origin also contained commits A, B and C
Only master branch is present
Commit A was the initial empty commit.
Commit B was where all contents was added, 14 folders and 16 files.
Commit C was another empty commit
Commit A and Commit C were both created using tools to assist with the migration. It runs two commands: "git init" and "git commit --allow-empty -m 'initial commmit'"
I could not understand how git status did not report the deleted files (I remember deleting them, but it was some days previously with multiple computer hibernates, and probably a restart or two from resuming my work)
Trying to figure out what had happened I did this:
I created a new file then ran "git add", "git commit" (creating D) and "git push."
Commit D appeared on the server with the new file. The 13 additional folders and files were still present on the server.
I ran "git pull" which returned "already up to date"
I checked the changes for every commit on the client side and on the server side and every diff was the same
I cloned a new copy of the repo and the contents matched the server with the 13 additional files and folders with the additional commit D and extra file
I then recreated a folder with the same name as one of the deleted folders and ran "git status" where finally all of the deleted files and folders were reported correctly.
I cannot explain this any other way except for a serious bug which simply makes it unsafe to use git in Cygwin. I hope the community may have some advice for me in this area and that this is phrased as a clear enough question that the mods don't flag my post.
I will do my best to try and reproduce the problem and update the issue with more info when I have some.
Edit: Update 2016-12-08
My attempts to reproduce the error have been unsuccessful. If I see it again during my work I will update this issue.
I've never seen such behaviour with Git on Cygwin. Actually currently I use Git for Windows from within Cygwin and it also works fine. I used to use the Cygwin Git, but I had the feeling that it is slower than Git for Windows, such I switched to Git for Windows used from within Cygwin and it works great.
If you at some point update the Windows boxes to Windows 10, you can also consider another option, the Windows Subsytem for Linux which is an Ubuntu based virutal Linux environment developed by MS together with Canonical. It is still in the process of getting mature and not fully usable yet in my opinion, but there you then have a natively supported virutal Linux environment where you can use apt-get and so on.
Issue you mentioned are really unexpected, and I doubt Cygwin can cause it. But you have following options
git comes with git bash, which support all major unix commands and it looks completely like unix shell. I am using git version 2.9 on windows 10 and heavily use major unix command like grep, sed & find , and they all work excellent. Even it support vi but I don't use it
git comes with git CMD, and same git commands will work on windows command prompt as they do on unix. You shouldn't need a separate emulator with this.
Though you mention you are using Windows 7, but now Windows 10 comes with native support for Unix Bash
You can use gnuwin32 but I doubt it will be better than Cygwin
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.
As part of our code repository, we have a symlink which is internal to the working tree.
Zend -> ZendFramework1.10/library/Zend
This works fine for all the developers running Linux or OS X, but we're now getting some people trying to use the repository on Windows.
The functionality of the symlink can be replicated by deleting the link git creates, and using mklink to create the equivalent directory junction.
However, git now sees this as the deletion of the symbolic link, and the addition of a proper directory.
I'm looking for a way to have the two co-exist, is there a way to tell the Windows machines to ignore the Zend directory, even though it's technically versioned. If this breaks when the files in that directory change then so be it, but it'd be nice to be able to work with the rest of the repo without having to worry about the link.
You can use git-update-index to tell git to ignore changes to the file:
git update-index --assume-unchanged Zend
You could probably use cygwin on the machines running windows.
As Magnus Skog has suggested, git under cygwin copes correctly with the symlinks. I switched away from Git for Windows for this reason alone. However you need to weigh up this advantage against the overhead of setting up the cygwin environment for your Windows users (particularly for those unfamiliar with *nix and the command line; for example there are a number of outstanding issues when trying to use Cygwin and TortoiseGit.)
I'm comfortable using git, and I prefer it very much over CVS. Unfortunately, in our company, we have to use CVS as a version control system. I was wondering if there was anyway to use git locally while committing to the CVS repo, and I was elated when I found this SO question. Unfortunately, it does not seem to work on Windows. I have Git For Windows (mysysgit) installed on my computer, and when I type git cvs or git cvsimport in the terminal it says "not a git command". Is there anyway I can use this functionality on windows?
Use Cygwin git instead of msysgit, it has this and other functions, like git daemon.
Or you can implement this feature and contribute it to msysgit.
I make that methodology work on Windows, but since our CVS server is Linux I do my export to CVS on that server, and then clone to my Windows machine. I push back through a staging repository also located on the Linux server.