209

I am a complete Noob when it comes to GIT. I have been just taking my first steps over the last few days. I setup a repo on my laptop, pulled down the Trunk from an SVN project (had some issues with branches, not got them working), but all seems ok there.

I now want to be able to pull or push from the laptop to my main desktop. The reason being the laptop is handy on the train as I spend 2 hours a day travelling and can get some good work done. But my main machine at home is great for development. So I want to be able to push / pull from the laptop to the main computer when I get home. I thought the most simple way of doing this would be to just have the code folder shared out across the LAN and do:

git clone file://192.168.10.51/code

unfortunately this doesn't seem to be working for me:

so I open a git bash cmd and type the above command, I am in C:\code (the shared folder for both machines) this is what I get back:

Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

How can I share the repository between the two machines in the most simple of ways.

There will be other locations that will be official storage points and places where the other devs and CI server etc will pull from, this is just so that I can work on the same repo across two machines.

As per Sebastian's suggestion I get the following:

C:\code>git clone --no-hardlinks file://192.168.10.51/code
Initialized empty Git repository in C:/code/code/.git/
fatal: 'C:/Program Files (x86)/Git/code' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

**EDIT - ANSWER **

Thanks to all that helped. I tried the mapping a drive and that worked so thought I would go back and retry without mapping. The final result was:

git clone file://\\\\192.168.0.51\code

This worked great.

Thanks

raam86
  • 6,785
  • 2
  • 31
  • 46
Jon
  • 15,110
  • 28
  • 92
  • 132
  • file://192.168.10.51/code is by no mean a valid URI pointing to a file, whereas file://C:\foo\bar.txt is – Gregory Pakosz Mar 25 '10 at 22:43
  • Then how can I point at a remote machine with such reference? – Jon Mar 25 '10 at 22:57
  • You probably want to map a network drive. – Josh Lee Mar 25 '10 at 22:59
  • worked for me - note this is specific to windows and won't work from git bash in windows - need to use cmd or powershell – Dave Rael Dec 31 '13 at 13:46
  • also tried it in cmd but it doenst work. And also what is "code" in "git clone file://\\\\192.168.0.51\code" means? I replaced it by "C:/UniserverZ/www/sampleProject/" and it didnt worked. It said that its not a git repository – Alex Coroza Jul 29 '16 at 09:15
  • You won't need to do `file://\\\\...` with Git 2.24 (Q4 2019). See my [edited answer below](https://stackoverflow.com/a/54965922/6309) – VonC Oct 05 '19 at 06:31

9 Answers9

184

You can specify the remote’s URL by applying the UNC path to the file protocol. This requires you to use four slashes:

git clone file:////<host>/<share>/<path>

For example, if your main machine has the IP 192.168.10.51 and the computer name main, and it has a share named code which itself is a git repository, then both of the following commands should work equally:

git clone file:////main/code
git clone file:////192.168.10.51/code

If the Git repository is in a subdirectory, simply append the path:

git clone file:////main/code/project-repository
git clone file:////192.168.10.51/code/project-repository
poke
  • 369,085
  • 72
  • 557
  • 602
  • 2
    is there a way to authenticate (ie username/password) with that scheme? – intuited Mar 26 '10 at 03:05
  • Hi that was almost there, I have editted my question to show final resul – Jon Mar 26 '10 at 10:58
  • @intuited: I don't think so, but the authorization request might pop up automatically. Or you have to open the share manually first (in Windows Explorer), as Windows saves the authorization during a session. – poke Mar 26 '10 at 12:39
  • From Windows machine: git clone file:///\\\\ – Michael Allan Jackson Dec 20 '11 at 03:49
  • 1
    @majgis I nearly use only Windows, so my solution works for Windows. – poke Dec 20 '11 at 08:17
  • 1
    yep this is the best way to do it in windows. – Nicholas DiPiazza Dec 04 '12 at 14:45
  • 3
    One could also use the **protocol:////user:password@host:port/path** notation, for example : **file:///user:password@192.168.10.51/code** – pistache Mar 14 '13 at 11:24
  • @pistache - I don't think that would work for the 'file' protocol, which just uses the standard file access routines and therefore has no was of passing a username/password to the system. I haven't tried it, but I'd guess that Windows will pop up a username/password dialog if you don't have an existing authentication method for the server in question (assuming you're running on a console associated with a graphical login session, that is). – Jules May 22 '13 at 08:47
  • I can't see a reason why using localhost won't work. Just tried that in OSX and it works perfectly fine. So instead of you IP in the network (which even may change all the time) just use "localhost".. or "127.0.0.1" – OderWat Jul 22 '13 at 12:32
  • 1
    @OderWat Except that using *localhost* will not help you at all when trying to access a different computer, which is what the question was about. If you want to access a *local* repository, i.e. that exists locally in your filesystem, you can just use a local path without using the file protocol… – poke Jul 22 '13 at 12:54
  • today I needed `file://///machine\sharepath`, exactly 5 slashes on the file scheme – DWR Oct 16 '20 at 15:13
133
$ git clone --no-hardlinks /path/to/repo

The above command uses POSIX path notation for the directory with your git repository. For Windows it is (directory C:/path/to/repo contains .git directory):

C:\some\dir\> git clone --local file:///C:/path/to/repo my_project

The repository will be clone to C:\some\dir\my_project. If you omit file:/// part then --local option is implied.

jfs
  • 399,953
  • 195
  • 994
  • 1,670
  • 7
    This worked for me for file paths with spaces: git clone -l file://"C:\SOME PATH\WITH SPACES" my_project – Sebastian Patten Feb 03 '12 at 15:26
  • 1
    Great help. This works for me in my windows 7 machine .something like : git clone file:///C:/Users/username/repsitoryName – Asraful Dec 31 '12 at 09:38
  • you will probably want to set the remote afterwards.. otherwise it points to your other local as origin which I find super error-prone. use git remote -v;git remote rm origin; git add origin (which you may copy after doing git remote -v on the original local repo) – Hanan Apr 24 '13 at 10:07
  • This is correct, you don't need to use a url form like file:////, you can just clone a directory. – Peter N. Steinmetz Jun 30 '14 at 18:57
14

the answer with the host name didn't work for me but this did :

git clone file:////home/git/repositories/MyProject.git/

Talaat Safwat
  • 161
  • 1
  • 4
9

I was successful in doing this using file://, but with one additional slash to denote an absolute path.

git clone file:///cygdrive/c/path/to/repository/

In my case I'm using Git on Cygwin for Windows, which you can see because of the /cygdrive/c part in my paths. With some tweaking to the path it should work with any git installation.

Adding a remote works the same way

git remote add remotename file:///cygdrive/c/path/to/repository/
Mark F Guerra
  • 892
  • 10
  • 13
7

Maybe map the share as a network drive and then do

git clone Z:\

Mostly just a guess; I always do this stuff using ssh. Following that suggstion of course will mean that you'll need to have that drive mapped every time you push/pull to/from the laptop. I'm not sure how you rig up ssh to work under windows but if you're going to be doing this a lot it might be worth investigating.

intuited
  • 23,174
  • 7
  • 66
  • 88
  • @Carlos: I think that will only work if you haven't `cd`'d to some other directory on the `Z:` drive. IIRC; I haven't been a Windows user in quite some time. Also it might be that `git` interprets drive letters differently from the standard Windows convention. Did you try `Z:\`? – intuited Nov 02 '10 at 00:35
  • errr... that should have read "did you try `Z:\\`?". Well, except with correct escaping so the code-mode gets enabled.. #nurrrr.. I guess not, anyway. – intuited Nov 02 '10 at 10:09
3

Not sure if it was because of my git version (1.7.2) or what, but the approaches listed above using machine name and IP options were not working for me. An additional detail that may/may not be important is that the repo was a bare repo that I had initialized and pushed to from a different machine.

I was trying to clone project1 as advised above with commands like:

$ git clone file:////<IP_ADDRESS>/home/user/git/project1
Cloning into project1...
fatal: '//<IP_ADDRESS>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

and

$ git clone file:////<MACHINE_NAME>/home/user/git/project1
Cloning into project1...
fatal: '//<MACHINE_NAME>/home/user/git/project1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

What did work for me was something simpler:

$ git clone ../git/project1
Cloning into project1...
done.

Note - even though the repo being cloned from was bare, this did produce a 'normal' clone with all the actual code/image/resource files that I was hoping for (as opposed to the internals of the git repo).

bargar
  • 584
  • 5
  • 5
2

Either enter absolute paths or relative paths.

For example the first one below uses absolute paths :

(this is from inside the folder which contains the repository and the backup as subfolders. also remember that the backup folder is not modified if it already contains anything. and if it is not present, a new folder will be created )

~/git$ git clone --no-hardlinks ~/git/git_test1/   ~/git/bkp_repos/

The following uses relative paths :

~/git$ git clone --no-hardlinks git_test1/   bkp_repos2/
Community
  • 1
  • 1
sidquanto
  • 315
  • 3
  • 6
2

While UNC path is supported since Git 2.21 (Feb. 2019, see below), Git 2.24 (Q4 2019) will allow

git clone file://192.168.10.51/code

No more file:////xxx, 'file://' is enough to refer to an UNC path share.
See "Git Fetch Error with UNC".

Note, since 2016 and the MingW-64 git.exe packaged with Git for Windows, an UNC path is supported.
(See "How are msys, msys2, and MinGW-64 related to each other?")

And with Git 2.21 (Feb. 2019), this support extends even in in an msys2 shell (with quotes around the UNC path).

See commit 9e9da23, commit 5440df4 (17 Jan 2019) by Johannes Schindelin (dscho).
Helped-by: Kim Gybels (Jeff-G).
(Merged by Junio C Hamano -- gitster -- in commit f5dd919, 05 Feb 2019)

Before Git 2.21, due to a quirk in Git's method to spawn git-upload-pack, there is a problem when passing paths with backslashes in them: Git will force the command-line through the shell, which has different quoting semantics in Git for Windows (being an MSYS2 program) than regular Win32 executables such as git.exe itself.

The symptom is that the first of the two backslashes in UNC paths of the form \\myserver\folder\repository.git is stripped off.

This is mitigated now:

mingw: special-case arguments to sh

The MSYS2 runtime does its best to emulate the command-line wildcard expansion and de-quoting which would be performed by the calling Unix shell on Unix systems.

Those Unix shell quoting rules differ from the quoting rules applying to Windows' cmd and Powershell, making it a little awkward to quote command-line parameters properly when spawning other processes.

In particular, git.exe passes arguments to subprocesses that are not intended to be interpreted as wildcards, and if they contain backslashes, those are not to be interpreted as escape characters, e.g. when passing Windows paths.

Note: this is only a problem when calling MSYS2 executables, not when calling MINGW executables such as git.exe. However, we do call MSYS2 executables frequently, most notably when setting the use_shell flag in the child_process structure.

There is no elegant way to determine whether the .exe file to be executed is an MSYS2 program or a MINGW one.
But since the use case of passing a command line through the shell is so prevalent, we need to work around this issue at least when executing sh.exe.

Let's introduce an ugly, hard-coded test whether argv[0] is "sh", and whether it refers to the MSYS2 Bash, to determine whether we need to quote the arguments differently than usual.

That still does not fix the issue completely, but at least it is something.

Incidentally, this also fixes the problem where git clone \\server\repo failed due to incorrect handling of the backslashes when handing the path to the git-upload-pack process.

Further, we need to take care to quote not only whitespace and backslashes, but also curly brackets.
As aliases frequently go through the MSYS2 Bash, and as aliases frequently get parameters such as HEAD@{yesterday}, this is really important.

See t/t5580-clone-push-unc.sh

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
2

After clone, for me push wasn't working.

Solution: Where repo is cloned open .git folder and config file.

For remote origin url set value:

[remote "origin"]
    url = file:///C:/Documentation/git_server/kurmisoftware
idanek
  • 39
  • 2