2

I have an existing Git repository, with working copy, connected to a GitHub remote repository (my local repository is on Windows).

I would now like to allow another developer to clone my local repository and connect to it as its remote repository.

Is this possible?

I have installed GitStack for Windows, but I see only the possibility of creating a new repository - not setting up an existing local repository to be used as a remote repository for another repository.

If this is not possible, is there some way I can set up my Git infrastructure so that I can achieve the same end - i.e., so that when the other developer commits, I do not have to do anything and those commits appear in my existing Git repository?

Dan Nissenbaum
  • 13,558
  • 21
  • 105
  • 181
  • As far as I know, a remote repository should be a **bare** repo. It means you need to `clone --bare` first. – Hashem Qolami Jan 18 '14 at 18:20
  • @HashemQolami That's what I was afraid of. Leading to my second question - is there some approach (workaround) that I can take to achieve the same end? – Dan Nissenbaum Jan 18 '14 at 18:21
  • You could have two repository on your system, one of them is a bare repo, and the other repo used the first one as a remote repo. but in this approach you still have to `pull` the commits from the *bare* repo. – Hashem Qolami Jan 18 '14 at 18:24
  • @HashemQolami, this is not correct. Non-bare Git repositories can definitely be cloned. – ChrisGPT was on strike Jan 18 '14 at 19:20
  • @Chris I know, but isn't there any limitation for updating a non-bare repo from the other users? – Hashem Qolami Jan 18 '14 at 19:30

1 Answers1

2

Yes, a regular Git repository (non-bare, with a working copy) can be cloned.

For example, assume your existing repository exists at C:\my-repo\. You can clone it to C:\my-repo2\ like this:

cd /d c:\
git clone my-repo my-repo2

Cloning it from another machine is a bit different, since you need to open up a network path to your existing repository. On a Linux system I would recommend enabling SSH or using git instaweb. Of course, both of these can work on Windows, but setting them up isn't nearly as easy.

Looking through the documentation for GitStack, you probably want to follow these instructions for importing an existing repository. Point GitStack at your existing clone and you should be good to go.

A note on pushing

As Hashem Qolami points out, by default the non-bare repository will not accept a push to its active (checked-out) branch. You have a few options here.

  • Read about receive.denyCurrentBranch in git help config and decide whether you want to enable pushes to the checked out branch. I wouldn't recommend changing this setting, but it should be mentioned as an option.
  • Have downstream developers push to a different set of branches. For example, decide that downstream developers will push to branches called developer-name/branch-name. Then merge the branches in the upstream repository.
  • Instead of having downstream developers push into the upstream repository, enable incoming Git connections to downstream machines as well and fetch (or pull) downstream changes into the upstream repository.
Community
  • 1
  • 1
ChrisGPT was on strike
  • 127,765
  • 105
  • 273
  • 257
  • BTW, I do have a static IP and have an SSH server already set up - WinSSHD (http://www.bitvise.com), so network access is all taken care of. I will try this now! Thanks. – Dan Nissenbaum Jan 18 '14 at 19:24
  • 1
    @Chris, please correct me if I'm wrong, it is not possible to push local commits to a non-bare repository, right? If so, how should other developers update the remote repo? – Hashem Qolami Jan 18 '14 at 19:29
  • @HashemQolami, you're correct that by default you cannot push to the active branch of a non-bare repository. I have updated my answer with some details about how this can be dealt with. – ChrisGPT was on strike Jan 18 '14 at 19:43
  • I am glad Option 2 exists. I do not mind having the downstream developers work on a different branch, and I will merge that branch into the working copy's branch as needed. I am attempting to get this set up now. – Dan Nissenbaum Jan 18 '14 at 20:07
  • Progress is being made ... there's actually a pretty simple solution in my case... I will update shortly, but in summary: Use GitStack to create a BARE repository FROM your working repository; therefore it's an up-to-date clone. Have the other developer clone THAT repository and push commits to it. Then, add that BARE repository as a SECOND remote repository to you working repository. Whenever you pull from your working repo's remote, push to the second remote (bare repo). Whenever the other developer commits, merge from the second remote into working copy and commit/push to the main repo. – Dan Nissenbaum Jan 20 '14 at 19:14