3

So I am going to migrate a bunch of repositories from bitbucket.org to a new on premise Bitbucket server instance.

What I can't decide on is whether to clone each repository as --bare or --mirror.

The scripted process seems pretty straight forward.

  • Get the repositories from bitbucket.org and write them to a file for use and to keep as a log. (already done and works)

  • Read the file, extract the repositories, repo slug(repo name) and clone them.(already working with --mirror)

  • For each cloned repo, run:

    • git gc --auto to cleanup repos
    • Create repo from slug on new on premise server
    • git remote set-url origin ssh://on_prem_server:7999/PROJ/REPO
    • git push --all origin
    • git push --tags origin

So I am not actually mirroring the bitbucket.org repos but migrating them. My understanding is that git clone --mirror gives a true copy of original. While git clone --bare does not and needs at least a fetch afterwards. This is why I initially thought using --mirror was best.

But now I am worried that there could be some danger in using a mirror.

So my questions are.

  • Are there any dangers using git clone --mirror I should be aware of?
  • Should I even use --mirror or is --bare good enough?
tdh
  • 103
  • 2
  • 11

1 Answers1

4

--mirror just means to copy all refs "as-is" (instead of, for example, copying only branches and mapping them to remote tracking refs). Your use case is within its range of intended purposes.

(Just to clarify - --bare also maps refs directly rather than creating remote tracking refs form branches, but it doesn't copy all the refs like --mirror.)

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
  • 1
    So whenever you use --mirror it only **ever** mirrors **one** way correct? I mean there is **no** possibility to push unwanted changes to the original upstream repository right? – tdh Aug 30 '18 at 13:48
  • 1
    @tdh - You're reading too much into the word `--mirror`. What the `--mirror` option means is what I've said above. As with any clone, by default the source repo is set up as a remote. If you push to that, your changes will be pushed to it. If you don't want to do that, don't (and you can always `git remote remove origin`). – Mark Adelsberger Aug 30 '18 at 13:54
  • Ok, Thank you for your responses! I appreciate it. I think the mirror is the way to go then. – tdh Aug 30 '18 at 14:10
  • I found this information at [Duplicating a repository](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/duplicating-a-repository#mirroring-a-repository), "As with a bare clone, a mirrored clone includes all remote branches and tags, but all local references will be overwritten each time you fetch, so it will always be the same as the original repository." It clarified things even more to me. Thanks to user @Eat at Joes for originally posting the link in [this question](https://stackoverflow.com/q/3959924/715036). – cb2 Jul 07 '20 at 11:40
  • Also as with other types of repositories, you can make sure to avoid accidental pushes with the likes of `git remote set-url --push origin no_push` (repeat for each remote that you want read-only). When explicitly needed, you can `git push $URL` anyway ;) – Jim Klimov Jan 15 '21 at 12:54