4

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?

Klaus
  • 24,205
  • 7
  • 58
  • 113

4 Answers4

5

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.

max630
  • 8,762
  • 3
  • 30
  • 55
1

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.
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

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.

TriskalJM
  • 2,393
  • 1
  • 19
  • 20
  • If I did a `git fetch --all` ow to deal with the clone after that? See my edit in my question. Your info for A2 is not very helpful. "There are several ways" is not a answer to the question how to do something. One way would help me :-) That there is a way is quite clear before your answer! – Klaus Mar 18 '16 at 20:46
  • @Klaus: I agree that my A2 was not a helpful response. One way to do this is with patches (and apologies for linking offsite): https://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ – TriskalJM Mar 18 '16 at 20:49
  • I'm unsure what you mean by _deal with the clone_? The clone should now contain all of the information that the original repo had, so you treat it the same as you would the remote, except that changes you make in the clone have to be pushed. – TriskalJM Mar 18 '16 at 20:51
  • Is the only way to checkout every branch on the local clone and push every single branch to the other remote one? – Klaus Mar 18 '16 at 20:53
  • If you want _all_ of the information to match, yes. But that's a `git fetch --all` and a `git push --all`. For a specific branch, you can do a `git fetch ` or `git push `. – TriskalJM Mar 18 '16 at 20:57
  • 1
    BTW: `git fetch --all` will look for all repos. But I can only reach one repo at a time. – Klaus Mar 18 '16 at 21:03
0

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
Yann VR
  • 486
  • 5
  • 9