I want to know if there is a way to have mirror
folders with a remote machine. I see some solutions for
syncing folders with a backup drive, but I am not interested
in that. I want to sync a folder with a remote machine through
ssh. I am on OSX leopard
Ted.
Check out the rsync command line utility. You may even be able to find some good GUI applications that build on rsync. Although I haven't tested it, Grsync looks promising.
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.
I have a Mercurial repository that is located on a NAS (Buffalo TeraStation). It is mounted on a Ubuntu machine and is mapped onto a Windows 7 machine.
I have previously been able to clone, update, etc. from both the Linux machine and the Windows machine, but now am having problems. Too many changes have been made (updating versions of hg, thg, etc.) to identify a specific point where things started to fail.
I can read and write files from both machines from/to the NAS. I can use "cp" to copy entire repositories, but if I attempt to clone using hg (or thg) it fails.
When cloning an existing (in the NAS) repository to the Ubuntu machine, all of the files copy over, but the operation is aborted with the message:
abort: Operation not permitted: (repository_path)/.hg/store/.phaseroots-94sdvj
[command returned code 255 Thu Jul 30 17:39:45 2015
When cloning an exiting (in the NAS) repository to the Windows machine, the cloning hangs (with no files transferred).
I have tried various [trusted] settings to no avail.
I have tried performing the hg clone command manually and it works properly when done with "sudo". However, the cloned repository then is owned by "root".
I'm pretty sure this is a permissions problem, but have run out of ideas. Any guidance would be appreciated!
One thing can think of is support for hardlinks on the NAS you are using.
For example some of the versions of Mercurial had problems with windows shares. For more information here.
I have no explanation for the problem on the Linux machine, but the problems on the Windows machine might be caused by this exact setup (cloning from a Linux drive to a Windows machine).
Years ago, I had similar problems (although with different error messages) when pushing from my Windows machine to repositories on a shared (Linux) NAS drive - see the link for more details.
But that was over five years ago and I didn't try it anymore since then, though.
I have to work on the same project in multiple systems for some reason. So I took external drive with FAT filesystem and copied my repo from OSX to the external drive. Now I want to be able to use GIT to work on that project from both systems OSX and Windows. But first I have problems with file permissions as FAT does not have permissions, the file permissions were changed when I was doing diff on both platforms. This was easily solved when I set:
git config core.fileMode false
But I cannot solve problems with symbolic links. I need them to be unchanged as I don't need them on Windows. As far as FAT does not support symbolic links, when I copied files form Mac to external FAT HDD something is changed in those files. Now I get diff only in Windows related to symbolic links. But I don't get any diff on OSX. How this can be? Symbolic link is also a file right? Now I don't understand the file is changed or no? Systems tell me different things? How to solve this problem?
Tries using this:
git config --global core.symlink false
but it didn't help, as, I guess, if works when you checkout. But I have only one repo and I don't do checkout to use it on Windows. I just use it from my external HDD.
The correct way to handle symlinks in git between multiple systems is to use it the way it was designed to be used, which is to have multiple clones and push and pull between them. So you'd have your original clone on the external disk, and one clone on each computer. When you push-pull between them, git will update the symlinks: How does git handle symbolic links?
I'd like to be able to do some development work on public/borrowed computers (where I have no root privileges) and I've managed to get most of my tools working off of a USB stick but I still haven't found a Git solution.
The portable versions of Git that I have found are Windows-only. Do you know of any Mac alternatives?
EDIT: I've gotten a few suggestions to just copy my current installation of git from /usr/bin and put that on a USB drive. That's a great idea but I don't have a current installation of git to copy from. I won't have my own computer back for a couple of weeks.
Would you happen to know where I could grab a pre-compiled version of git for OSX? I don't have access to homebrew or... anything really. Ideally I could just grab a zip file from somewhere and dump it on my USB stick.
I've managed to put together a solution based on ideas from several different people (thanks to all of you):
Download the Git binary for Mac OSX from git-scm.com. The downloaded DMG contains a PKG file.
Unpack the PKG file with unpkg or something similar. (This step is necessary because normally PKG files can only be installed with root privileges.)
Drop the etc and git folders that were just unpacked onto your USB stick.
Now, whenever you plug in your USB stick, just make sure to put the location of the git directory on your PATH (like this: export PATH=$PATH:/path/to/git/on/usb/stick) and you'll be good to go!
NOTE: I've tested many of the git commands using this method and most seem to work without any issues. However, git init will complain like this: warning: templates not found /usr/local/git/share/git-core/templates. Not surprising since the templates are actually on your USB stick and not /usr/local. Despite this warning my repos seem to be working just fine.
Add a environmental variable GIT_TEMPLATE_DIR
to quote the documentation
The template directory contains files and directories that will be
copied to the $GIT_DIR after it is created.
The template directory will be one of the following (in order):
the argument given with the --template option;
the contents of the $GIT_TEMPLATE_DIR environment variable;
the init.templatedir configuration variable; or
the default template directory: /usr/share/git-core/templates.
I've uploaded my /usr/bin/git and /usr/bin/git-shell to
http://www.club.cc.cmu.edu/~ajo/disseminate/git
http://www.club.cc.cmu.edu/~ajo/disseminate/git-shell
You can try those, but I have no idea if this approach is likely to work. (There are no interesting shared-library dependencies reported by otool -L, but I don't know what else might theoretically go wrong with the idea.)
FWIW, I use Mac OS X 10.8.2 and git version 1.7.10.2 (Apple Git-33).
Not sure if this is appropriate as an "answer", since I don't plan to leave those links working indefinitely. Maybe I (or someone) can delete this answer in a month or two.
Apple's command line tools for developers include git, I believe. You can find them on http://developer.apple.com/; you might need a free developer account. They package will want to install to /usr/bin etc., but you should be able to use pax to extract the contents wherever you want.
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.)