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 [1] 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 

 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 

Reply via email to