I am working on an iOS project. I just created a local repo for my project on Mac. Due to some reasons, I have to transfer it to a windows machine to place it a shared folder. I do not have access to that shared drive from my Mac.
How do I proceed with creating a repo that can be shared? I am at a point where I have all my code committed in local repo. Please advice..
Thanks in advance..
You have a few possibilities:
Just copy the repo to a USB key or external disc, and then transfer to the PC. Git repos can always be transferred, you do not need to do anything special: the on-disk format is always the same. Although you may encounter some issues with file encoding (Windows or UTF-8): it would be good to configure both gits to use UTF-8. Optionally you can zip your repo folder and unzip it on the PC.
Upload to dropbox or similar file transfer service. Same as above.
Share the code on github or a similar public git service. This is by far the best option, although (if the code is not under an open source license) it may cost you money. Upload to github, download from the PC.
Hope this helps.
Related
I'm new to Git, and setting up a new repository on one of my own windows servers on my local network, with a view to being able to share source code with another developer on my network.
I have installed Git on my local windows PC, and have created a local repository for one of my existing projects.
I have also set up a shared folder on \myserver\Git Repository\
I have done a commit to the local repository, and am now trying to push that to the shared repository on the server.
I am not 100% sure what format I should be using for my URL, but the most promising error I can get is:
Pushing to file://myserver/Git%20Repository/Inhouse/File%20Comparer/.git
fatal: 'C:/Program Files (x86)/Git/Git Repository/Inhouse/File Comparer/.git' does not appear to be a git repository
fatal: Could not read from remote repository.
Why it is looking in program files folder, I have no idea.
I'm trying to keep things simple (to start of at least), and so have been avoiding using any other protocols.
I've tried googling, to find URL examples, but I just can't seem to get past this error about Got looking for the repository in the program files folder.
Any ideas?
Thanks In advance.
Maya
Got it working!
Instead of googling Git+local network share, I specifically added "windows" to my search too, as all the other information I was finding applied mostly to Linux servers.
This link helped the most:
http://elegantcode.com/2011/06/18/git-on-windows-creating-a-network-shared-central-repository/
I still didn't manage to get the //myserver/myshare/myprjectrepo working, so I mapped the share to a drive letter, and used R:/myprojectrepo instead. All working now.
I would like to use Git for a software project which resides inside an encfs enctrypted drive mounted via Dokan (Windows environment). The Encryption of the files works just fine, unfortunately Git does not seem to like working in this environment. When initializing the Git repository I encounter the error message:
error: could not commit config file w:/djangodance/.git/config
When committing I encounter this - disk is writeable and quota is not exceeded:
fatal: Repository has been updated, but unable to write new_index file. Check that disk is not full or quota is not exceeded...
So far I have learned that Git does not seem to like certain drive-mounting-setups. This article (mounting remote filesystem via sshfs) proposes a workaround option (-oworkaround=rename).
My questions:
Did I locate the source of the problem correctly?
Is there some similar setup for Dokan which works with Git?
Is there a different approach which could satisfy on-the-fly encryption using Windows? I'd rather not use TrueCrypt since it is not as useful in combination with Dropbox.
Thank you for any hint!
Dokany is a fork of Dokan. It is very active by the maintainers and the community. It is now know as the main solution for writing driver and porting FUSE to Windows with the same code.
It also have the fix that you would be interested:
https://github.com/dokan-dev/dokany/pull/39
There was a problem with MoveFileEx. Without the fix this API fails with "permission denied" because the target file is opened and cannot be deleted.
Now the git command works via dokan!
The latest release of Dokan appears to be nearly three years ago. I don't imagine you'll get much support with it, even from the community.
You may want to consider using Bitlocker, a full-drive encryption system. Or possibly Encrypting Filesystem to encrypt your development directory. Both of these options are included in recent versions of Windows, and should be fully supported by Microsoft.
I like to keep my local Git repos in my Skydrive folder so they sync nicely between machines and I always have an online copy. However, I've recently run into problems after upgrading from Windows 8 to Windows 8.1.
Specifically, I started getting errors that [hash] object was missing or corrupt. After debugging the issue, it turned out that Git was having difficulty with 8.1's new Skydrive integration into the file system. Specifically, 8.1 likes to list files as if they're stored locally, but keep them online until they're accessed. It turned out that right clicking my repo folder and clicking 'make available offline' solved the git errors.
Is there some convenient git or windows setting that I can change to make this unnecessary? It's not a big deal to make files available offline (in fact, I'll probably do that anyway), but I'd like to know if there's a neater solution.
You don't keep a git repo in a synchronized folder (Dropbox, SkyDrive, ...): too many files, too many corruption possibilities.
What you keep is a bundle:
one file
which can be incrementally updated,
and which represents your git repo
and from which you can clone a local repo
See:
"Git with Dropbox"
"Using Dropbox to synchronize files and having them backed up in version control"
"Git with Dropbox Issues"
Or, you can push those repos to a private repo hosting service like BitBucket, as commented by ta.speot.is.
TortoiseHg is sending me mad! No pun intended.
I am a solo .NET developer just trying to achieve good source control e.g. diff and revert.
I wish to have a central repo on a network share e.g. "\\server\repos\DO I NEED A FOLDER HERE"
and a local copy e.g. "... My Documents\Visual Studio 2010\Websites\My Website"
but the quick start guide http://tortoisehg.bitbucket.io/manual/2.4/quick.html is not relevant in my case - I don't think I want to clone the repository?
Please could someone outline the steps and their order to achieve:
Local copy
Central repo on network share (which is backed up regularly)
E.g.
Create folder for repository "\\server\repos\My Website"
Link ".. My Documents\Visual Studio
2010\Websites\My Website" to repo
Add files / commit files - I'm unsure of the terminology here
or point me in the direction of some idiot-proof documentation.
I chose TortoiseHg because I thought it was modern and simple.
Should I have gone with Source Gear Vault instead?
Any help appreciated!
I'm far from an expert but I believe that you do want to clone the repository to start with. You will treat your network share just as any other "server"(bitbucket, etc). So you clone from the network share to your local machine. Then any commits you do will be on your local machine. When ready to send to the network share then just do a push. The process is exactly the same but instead of some web address you can push to your network share.
What I would do is create the repository on your network share. Then I would clone it locally. It really is simple. Once you have mercurial installed, you can just hg init any directory and you have a working repository. Then it's just a matter of setting up the shortcuts to point to the right places so you can do something like hg push netshare instead of hg push \\server\repos etc.
Also, adding files is not the same as committing. When you add files you are telling mercurial, "Hey, I want to keep track of changes to this/these files". When you commit, you are telling mercurial, "I've modified my files and I want you to record the changes since the last time I committed".
After reading Michael Lopp's book "Being Geek," I started using Dropbox as a means of synchronizing files between my home computer and work computer. It's been fantastic, it really makes it painless to keep track of the latest version of files you're working on.
My question has to do with people's experience with this tool, especially programmers who may have used it to develop larger projects.
Right now, I see 3 main uses of Dropbox:
1. synchronize files between home and work computers
2. version control (you have to log into the dropbox site to access previous versions)
3. off-site backup
Right now I'm using it as my main backup tool, which I'm not sure is a good idea. But right now I have a local (working) copy of my entire project "checked out" on each computer (my home laptop and my work computer), and additionally, my entire project is kept on the dropbox site. So I'm thinking, if anything happens to one of my computers, or both, I'll still have that off-site backup available and I'll simply have to reinstall dropbox to access all my files.
Does anyone have experience with doing this? Has anyone done a major file recovery using dropbox? Or is this even widely used? Thanks for your feedback in advance.
Using Dropbox to maintain several files and its associated metadata when those files are historized in a VCS is always a bit tricky because of potential corruption issue (if one of those metadata part of the repository isn't correctly synchronized, you can end up with a non_working repo)
That is why I always use with DropBox:
a DVCS (like Git): I can work directly in a working tree within a DropBox repo or I can clone said repo anywhere else outside the DropBox if I need to,
a single bundle file to which I can push at any time the changes from my local repo, wherever that repo might be.
That way, the only file that really need to be in sync in DropBox is that unique bundle file (representing a bare repo as one file).
See "Git with DropBox" for more.