copy a branch from one to another repo

Question

I have two git repos which should be kept in sync and can NOT be accessed at the same time. One is at work and one is at home and there is no network connection possible.

How to handle this simple setup?

What I have tried:

I have a clone which "knows" both repos and exist on a portable harddisk.

Lets say someone has created a new branch at "work" and I want to transfer it to the repo "home". How to do this?

If I only do a git pull I get the following on my clone:

$ git branch --list --all
*master
origin/HEAD -> origin/master
origin/bugfix_component_condition_destruction_fail
origin/master
origin/remove_stoplist_copy_and_erase

Q: Did this only mean that my local clone "knows" that there are these listed branches somewhere and no real data is on my clone expect for the also local existing one named "master"?

It is easy to pull/push master to both repos. But any other one seems not existing on my local clone. Must I track every remote branch to a local one of my clone and then transfer it to the other repo?

Q: Is there any typical way to deal with two repos to get them both in sync if on both repos commits will be pushed?

Q: Is there a trick to get all infos AND ALSO THE CONTENT of all remote branches.

For me it is a bit misterious what a "clone" of a repo means? It seems not a real clone but only some meta data and the master branch. Is this right?

EDIT:

If I start gitk --all I see all the changes which are done in the branch. That looks that the content of the branch is in the clone.

But if I do:

$git checkout -b remove_stoplist_copy_and_erase --track remotes/origin/remove_stoplist_copy_and_erase
error: Not tracking: ambiguous information for ref refs/remotes/origin/remove_stoplist_copy_and_erase
Switched to a new branch 'remove_stoplist_copy_and_erase'

So I did:

$git checkout origin/remove_stoplist_copy_and_erase
$git checkout -b remove_stoplist_copy_and_erase

and now push it: $git push --set-upstream ex remove_stoplist_copy_and_erase

I fear to must do all this manually for all branches on both remotes to get the both in sync. Is there some "best practice" for the job?

Answer 1

You can use bundles for that. No need to have full repository on portable disk

Let's call them repo1 and repo2

At repo1 you call:

• $ git fetch <bundle2> 'refs/heads/*:refs/remotes/repo2/*' to import changes from bundle file created at repo2
• $ git bundle create <bundle1> --all --not --remotes=repo2 to create a bundle for sending to repo2

At repo2, correspondingly:

• $ git fetch <bundle1> 'refs/heads/*:refs/remotes/repo1/*' and
• $ git bundle create <bundle2> --all --not --remotes=repo1

The manpage contains more information and examples.

Answer 2

A1: Yes, you need to execute git fetch --all on your clone to grab all of the remote branches.

A2: There are several ways to accomplish this, but they're all procedural (not in the software engineering sense).

A3: See A1.

Answer 3

Simple, add your work origin to your local repo:

• git add origin-work [path-to-work-repo]

Then fetch all branches:

• git fetch origin-work

Answer 4

Did this only mean that my local clone "knows" that there are these listed branches somewhere and no real data is on my clone expect for the also local existing one named "master"?

You will see more detail with Git 2.36 (Q2 2022), which gives hint when branch tracking cannot be established because fetch refspecs from multiple remote repositories overlap.

See commit e4921d8 (01 Apr 2022) by Tao Klerks (TaoK).
^{(Merged by Junio C Hamano -- gitster -- in commit ba2452b, 04 Apr 2022)}

tracking branches: add advice to ambiguous refspec error

^{Signed-off-by: Tao Klerks}

The error "not tracking: ambiguous information for ref" is raised when we are evaluating what tracking information to set on a branch, and find that the ref to be added as tracking branch is mapped under multiple remotes' fetch refspecs.

This can easily happen when a user copy-pastes a remote definition in their git config^(man), and forgets to change the tracking path.

Add advice in this situation, explicitly highlighting which remotes are involved and suggesting how to correct the situation.
Also update a test to explicitly expect that advice.

git config now includes in its man page:

ambiguousFetchRefspec

Advice shown when fetch refspec for multiple remotes map to the same remote-tracking branch namespace and causes branch tracking set-up to fail.

The advice:

There are multiple remotes whose fetch refspecs map to the remote tracking ref '<orig_ref>':
<remotes_advice.buf)>

This is typically a configuration error.

To support setting up tracking branches, ensure that
different remotes fetch refspecs map into different tracking namespaces.