On Fri, Apr 14, 2023 at 04:38:34PM +0200, Uwe Brauer wrote: > I would like to run a test and have a mirror of > matlab-emacs at sourgeforge > > At gitlab. > > So first step I clone the sourceforge repository > > git clone o...@git.code.sf.net/p/matlab-emacs/src > > Then > > git branch -a > > Shows me > > * master > remotes/origin/HEAD -> origin/master > remotes/origin/copyright > remotes/origin/documentation > remotes/origin/fontlockhang > remotes/origin/hairyblocks > remotes/origin/mac_init > remotes/origin/master > remotes/origin/modernize > remotes/origin/shellcomplete > remotes/origin/strings > remotes/origin/usage1 > remotes/origin/wisent-parser > > I create a repository at gitlab (private for the moment) and run > > git remote add gitlab g...@gitlab.com:kalthad/matlab-emacs.git > > and then > > git push -u gitlab --all > > However despite the option --all > > only the master branch is pushed. > > Does this mean I have to checkout all the remaining remote branches, 10, > before run git push -u gitlab --all? > > Is there any quicker way?
Well, your approach is incorrect. ;-) A correct one is going to be quicker, too. As I've explained in this list in the past, _by default_ Git implements asymmetric approach to handling remote repositories and branches they contain - you might want to re-read  and may be the whole thread; may be this idea will now have greater chances to really sink in as you will be able to compare and contrast "normal" clone and "mirror" clone. OK, a quick refresher on that asynchronous nature of "normal" Git repos. Even if you bring to life some local repository by cloning an already existing one, and intend to only communicate with that "origin" repository, Git does not really somehow establish such one-to-one relation between these two repos. A branch named "foo" in your local repository is still your local "foo", and, say, it won't be automatically updated when you fetch from the remote, and it won't be deleted if it's deleted on the remote. If you need mirroring, you're going to use mirroring, which sets up the clone in a way so that local "refs" (branches and tags) are always _replaced_ by the changes done on the mirrored remote repo, and then in the cloned repo you add another remote - for your GitLab-hosted repository - also instructing Git to do "mirror pushes". Here's how: 1. Clone the original repo: git clone --mirror o...@git.code.sf.net/p/matlab-emacs/src Note that a bare repository is created. That means, it has no work tree (no checked out files). You can now `cd` to the resulting directory and do `git branch` (note the absense of "-a" or "-r") and `git tag` there to see that all the branches and all the tags are here. 2. Configure a named remote in your clone: git remote add gitlab --mirror=push g...@gitlab.com:kalthad/matlab-emacs.git 3. Do the initial push: git push gitlab Observe everything getting pushed up. 4. Next time, when the original repository has new stuff, you do cd cloned_repo git fetch origin git push gitlab That is all. It will work because the cloning operation has set the resulting repository up in a way so that fetches update the local refs directly - as opposed to manipulating those so-called "remote branches", and the named remote in the resulting repo has been set up to do "mirroring pushes". 1. https://groups.google.com/g/git-users/c/IaH4Wlf3Ebo/m/iYffiJmpBgAJ -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20230414152623.7wagcebgkipxamvy%40carbon.