Git doesn't clone all branches on subsequent c

Question

I have some problems with Git using cloned repositories and branches and it's somehow not possible for me to find an answer to this. Let me describe: we have a bare master Git repository here we all pull from and push to, located on a local linux machine and reachable with ssh. I made a clone of this to my usb thumb drive like this:

git clone ssh://adahl@gollum//net/repos/netcube/patches.git

This gives me of course a local clone with a working copy on my thumb drive. I cd to this and see some branches in this clone then:

cd patches
git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/stable

So far so good, however if I clone the repository on my thumb drive another time to my notebook the stable branch is lost. See:

cd ..
git clone patches patches2

cd patches2

git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

I tried several options when cloning or a git fetch after cloning, nothing brings the stable branch to the patches2 repository. I assume I have a lack of understandig git here and simply use it the wrong way. Could someone please point me to my error in usage and/or understanding?

Answer 1

In addition to @ThiefMaster:

I like to

git clone --mirror

or

git push --mirror 

to update all (local & remote) branch refs and tags

Additional info As noted, --mirror will really replicate the repo as is, thus overwritany changes in the destination. Branches that do not exist in the source will get pruned unconditionally.

Essentially, it is like working with a remote and doing 'git remote update --prune', the difference being that the branches affected can be local branches as well as 'remote' refs[1]

@LeSpocky (and others?)

Now if changes disappear, they will never generate merge problems, so that's easy.

--mirror is named after the real-life concept, so it was designed to pave over any differences in the target. If the target is non-bare, and you had local changes committed, you can always get them back via the reflog of the target's local branch (git log -g, git reflog).

As a general safety measure you could have a hook to 'git stash save' in the target.

Keep in mind though, that --mirror was designed to, well, mirror and this question was in fact on how to replicate all branches to a bare remote. :)

[1] (the refs are there, but the remote definitions don't get copied; if you want that, do a manual copy from .git/config to .git/config on the push destination)

Answer 2

$ git remote update
$ git pull --all

Answer 3

See How to clone all remote branches in Git?

You need to create a local branch based on the remote branch if you actually want it to be included in a clone. However, since you don't work in remote branches anyway you'll create local branches as soon as you start working on a branch. And before that you don't really need it in your clone since you can simply fetch it from remote at any point.

However, if the notebook has no network connectivity, you'll have to create local branches for all remote branches you want so they are cloned when cloning your local repo.

If you do have network connectivity however, use git remote add origin2 ssh://adahl@gollum//net/repos/netcube/patches.git and then git fetch origin2 - feel free to replace origin2 with a more meaningful name.

Answer 4

"origin" is the default name given to the place you cloned the repo from, which is automatically added as a remote (note: remote just means "a repo not the current one" - remotes can be on the same machine).

In patches, "origin" refers to the original repo on gollum.

In patches2, "origin" refers to patches.

Remote tracking refs (the ones that begin with remotes/) are not actually local branches - they're just pointers to where branches were last known to be on the remote. Thus, in patches, you have remote tracking refs for the original repo, but on patches2, you only have a remote tracking ref for the local master branch in patches, because that's where patches2's origin points to.

You can use git remote add to add the original repo as another remote in patches2 after cloning it - or you could just clone again from the original repo instead of from patches.