Only the remote's local branches are cloned, not the remote's remote tracking branches

[kaba2]

I'm trying tomono as follows:

• Clone repositories A and B from server to local machine.
• Run tomono on local A and local B.

The problem is that only master branch gets handled, although local A and local B have many remote branches. The solution is to track the remote branches in A and B first:

for i in $(git branch -r | grep -vE "HEAD|master"); do 
    git branch --track ${i#*/} $i; done

Then tomono does it job as expected.

Should tomono be changed to somehow consider also the untracked remote branches in A and B?

[hraban]

Hi @kaba2 , this is a good solution to a common use case which I'm happy to add to the README as an instruction.

However, I won't add the functionality directly to the script. The recommended way to use tomono is to cut out the middle man, and add those remotes for A and B directly as remotes in your monorepo. Particularly because this allows you to later continue pulling in updates from those remotes.

To be honest, I'm not sure it's even possible to fetch a remote's remotes. It's definitely not common nor expected: remotes are (ironically) "local" to a git checkout. E.g. if I fork a popular github repo, I add two remotes to my local computer's copy: upstream (the original repo) and origin (my github fork). How would you decide which one to fetch? It'd be an unintuitive feature.

[kaba2]

Thanks @hraban for the reply, and also for writing this script. The reason I am running tomono for my local repos is that the repositories at the server are large, and my download speed for them is slow. Since I have the local clones already, I am able to save time, at least test the idea out. I wonder if there is a way to swap the remotes from the local repos to the server repos after tomono has done its job? Is it just a matter of git remote set-url? (I'm not very good at git). The goal would be to get the exact same result as if tomono was run directly for the server repos, without needing to download them.

[hraban]

Yes, it's exactly git remote set-url, you're right :)

In combination with the creation of local branches which track remotes, as you did above, the end result should be indistinguishable from piping the remotes in directly. It should at least be an interesting test.