Can Git clone a bare repository to another bare repository

Question

I'm sure this can be done, i'm just not sure of the right way.

My scenario is to have a USB drive, a local hard drive and a network drive all connected to my PC at this point. The local hard drive will contain the local active repo for my local work. The network drive (with a long UNC path!) would contain the main bare repo that acts as the upstream reference copy (2 or 3 collaborators in the office), while the USB drive acts as my mobile copy for sneakernetting to some external PCs (my other collaborators have their own drives, which may affect answers). (this is on windows msysgit).

It is the setting up of the USB drive that is the concern, and making sure I'm directing the workflow in the right direction (see using-git-on-usb-stick-for-travelling-code .

• Should I be cloning my local repo, or cloning the network repo?
• What are the special flags to make sure that the USB drive dismounts correctly? (-nohardlinks?)
• etc.

Answer 1

You can create a bare-to-bare clone from the repo with the long UNC path to the USB stick with

cd /e/src
git clone --bare //server/path/to/your/network/repo.git

but I doubt it buys you much to do it in one step.

Given that you'll be working in your local active repo, I'd create a bare repo on the USB stick

cd git init --bare /e/src/myproject.git

create a remote in your local active repo

git remote add usb file:///e/src/myproject.git

and then push to it as necessary.

git push usb philip/cool-new-feature

The commands above assume your USB stick is E: and that your working directory is within your local active repo.

As I understand your question, you have at least two disjoint sets of collaborators, depending on whether your other collaborators share a common central repository of their own or are all working on isolated machines. This means the repository on your USB stick is the repository to which everyone (eventually) has access, so your teammates spend most of their time “on a plane” with respect to it.

Suggestions for designing your development process:

1. Avoid the situation where you or someone else becomes The Designated Merger. Instead, you want all members of the team to integrate as frequently as possible to keep potential for conflicting changes small and manageable.
2. Having disjoint collaborators increases the risk that someone will break a feature that someone else depends on, either through seemingly innocuous changes or incorrectly resolving merge conflicts. You should have a quick, one-button method of determining whether any regressions or new bugs have snuck into your code.
3. Each group of collaborators, i.e., those who have more frequent access to each other's repositories or a shared repository than to your USB stick, should practice continuous integration among themselves. When new commits from the USB stick are available, integrating what they have with new code from the rest of the team should become top priority.

One way you might do this is to have everyone keep a clean master and make changes only on other branches. Physical possession of the USB stick is a natural integration token, so when a given collaborator has it, the sequence goes

git checkout master
git pull usb master     # should always be a fast-forward
git merge feature1
make test               # or whatever, and repeat until no breakage
git commit
git push usb master
git push shared master  # if appropriate
git merge feature2      # if necessary
...