Push to a remote repo

We already have automatic pull from another repo.

Would be nice to be able to push to another repo too.

This way I can keep GitLab.com and my local server in sync.

I think you should be able to enable both push and pull and they should allow fast-forward and non-ff merges

/cc @dzaporozhets @JobV @DouweM

If there are no technical difficulties with this, 8.6?

Milestone changed to 8.6

Added ~139512 label

Added ~139607 label

Nice idea.

1. We can re-use some code from Read-only server feature that is planned earlier.
2. I think we want both pull and push functionality on one page. Mirror Repository page should be good for it.
3. Push can be only fast-forward.

mentioned in issue #76

mentioned in issue #240

Simple way to do this https://smcleod.net/mirror-gitlab-to-github/

Reassigned to @brodock

Assignee removed

also would be great if I could have ability to specify multiple remotes

Reassigned to @rdavila

is it also possible to trigger sync when merge request is merged? - or that's already covered?

@mpapis MR merge is a type of push, so yep!

@DouweM I've a few questions by now:

1. Should we have the ability to enable remote push per branch? I don't think we want to push all the branches all the time, some of them can no longer exist on the remote repo.

2. What to do when a branch has been removed on the remote repo? Should we remove it on the mirror or only disable remote push on it?

3. What is a FF push is not posible? Should we try to merge the remote branch and push again or only let the user know about it and provide some guidelines to do this through the terminal?

@rdavila

The existing "Mirror Repository" feature is for when the original repo is somewhere else, and GitLab should be the mirror. This issue is about the case where the original repo is on GitLab, and the mirror is somewhere else. The intention is to keep the remote repo fully up to date with any changes to ours, so if a branch is deleted from the repo repo, we just push it again. When it is deleted from ours, we delete it there as well. The only exception is when the remote branch has been updated, in which case we can't push to it without losing commits. In this case we shouldn't update it, and we shouldn't delete it.

If the fast-forward update is not possible, we can do like we do with "Repository Mirroring" now, and show a tooltip like "The remote branch has diverged and could not be updated." We can basically use the same logic and text, but just flip the "remote"/"local" around.

@DouweM A while ago I created #240 , do you think that would be (technically) possible as part of this feature?

mentioned in merge request !249 (merged)

mentioned in issue gitlab-com/marketing#11 (closed)

mentioned in issue gitlab-com/blog-posts#167 (closed)

mentioned in merge request gitlab-shell!43 (merged)

@boudekerk Nice idea, but unrelated :) This issue only concerns syncing of the Git repo data.

Removed ~139607 label

@mpapis Do you have any suggestions related to this feature? What do you think would be useful in your workflow? (I talked with Michał about this feature, a few days ago).

Hi,

Small questions about this feature reserved for EE Version. After the various controversies around GitHub , imagine that each can host its self instance gitlab keeping github as a mirror. Which could give more users, more lift , thus more visibility and more love for gitlab. I think many research this function to get rid of github. that's why I think this feature could push to the CE version.

Thx

@grzesiek most important push to more then one repository.

I can not agree with @DouweM about removing remote branches, I think it would be better as option, for me the remotes are not just a backup, they are also the archive of all the past, so I would like the remote branches even if we remove some of them on GitLab.

/cc @rdavila

@mpapis To truly mirror repositories, we need to keep the branches synced as well. I want to understand your use case, why would you remove some branches from GitLab if you wanted to keep them? Why not just not remove them?

@DouweM it depends if the purpose is to mirror or backup/archive, for me it's more about archiving information, my project has installation infrastructure based on github branches, I do not want any of the branch removals reflect users that use the infrastructure, if there is something very wrong with the branch in question - I would remove it manually from github.

another question would be if we can force push diverging branches if the push to GitLab was also pushed.

for master we do not do that, but when working on different branches it might happen that we amend the last commit and we force push, I would expect a forced update to the remotes too.

@mpapis

another question would be if we can force push diverging branches if the push to GitLab was also pushed.

Good point. Overwriting remote branches (except for master) in the case of a forced push is valid.

I think that in a next iteration, we should allow more control of the delete/override behavior, so we can disable propagation of branch deletion, and enable overwriting of branches other than master.

cc @rdavila

Status changed to closed by merge request gitlab-shell!43 (merged)

Status changed to closed by commit gitlab-shell@91e72255

Status changed to reopened

Milestone changed to 8.7

mentioned in commit gitlab-shell@91e72255

@rdavila what is the ETA on this? We can use it for https://gitlab.com/gitlab-com/operations/issues/157

mentioned in issue gitlab-com/operations#157 (closed)

@sytses it's basically complete, just two small issues to address:

1. Improve the sync of tags by pushing one by one: http://stackoverflow.com/questions/5195859/push-a-tag-to-a-remote-repository-using-git
2. Protect the credentials from the repo URL.

@DouweM mentioned that we can skip number 2 by now, if so I can have it ready for tomorrow. This was Douwe's POV about number 2:

We can skip the credentials protection for now, as long as we don’t show the URL to anyone without master level

Which we don’t since we only show it in settings

Credentials encryption can go in a next version

mentioned in merge request gitlab-shell!46 (merged)

mentioned in commit gitlab-shell@f4f4b419

mentioned in merge request omnibus-gitlab!732 (merged)

mentioned in commit omnibus-gitlab@1217637a

Status changed to closed by commit 7cce76b60ff3f1f9b854c353e46943e7e073e6d7

Status changed to reopened

Status changed to closed

mentioned in commit 7cce76b6

mentioned in merge request gitlab-com/www-gitlab-com!1886 (merged)

@DouweM @JobV @dzaporozhets I am writing blog post about this feature.

I am curious what usage scenarios we initially had in mind.. I mean what problems can be solved with this feature.

I got real life use case, I will be moving rvm to gitlab, we have installation infrastructure based on github - so with the hook I can move the code without changing the installation code and all the past installation using the old code pointing to old installation will still work as expected.

@mpapis Awesome!

@inem @mpapis I got a repository syncing back to github too (I've created a personal token there to authenticate and be able to push), and I did that so people who forked or used my project before keep getting updates until they decide to start contributing using gitlab.

@inem We just started using this for our Infrastructure runbooks. We want them to be public, so they're hosted here, but the information in them is needed when GitLab.com is down, so we push to the remote mirror on dev.gitlab.org so they're always available.

@mpapis, @brodock, @rspeicher thank you for your use cases! going to use them in the blog post.

@inem I see you have enough usage scenarios already. Thanks people!

Mentioned in commit pfjason/gitlab-ce@7cce76b6

mentioned in commit 084f6209

mentioned in commit 18da0f9b