How do I move things from my Overleaf git repository to my Gitlab git repository?

Question

I've been using mobaXterm on a Windows 10 computer (based in Cygwin) as a terminal to access ROOT and Python scripts/macros. Additionally, my peers and I have been using Gitlab to share these scripts/macros. Recently, we begin working on a LaTeX document that has been shared also using Gitlab. The problem I've been facing is trying to integrate using Gitlab with me using Overleaf as my LaTeX editor.

I followed the guide given Here on how to link Overleaf's git repository with Github, only to run into some annoying issues.

First off, it seems as if I was able to git clone the Overleaf repository to my computer, via this line: git clone https://git.overleaf.com/%%%%%%%%%%%%%% note_name

Followed by git remote rename origin overleaf

Then I did pull via the line git pull overleaf master

None of this seemed to cause any problem. I then added my Gitlab repository via the line git remote add gitlab https://gitlab.thing.ty/folder/note_name.git

Then I did a preliminary push to Gitlab via git config --global push.default matching and git push gitlab

Username for 'https://gitlab.thing.ty':
Password for 'https://[email protected]':
Counting objects: 21, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (20/20), done.
Writing objects: 100% (21/21), 50.81 KiB | 0 bytes/s, done.
Total 21 (delta 7), reused 0 (delta 0)
To https://gitlab.thing.ty/folder/note_name.git
   ccf7614..596ba69  master -> master`

Followed by a pull from Overleaf git pull overleaf master

remote: Counting objects: 5, done
remote: Finding sources: 100% (3/3)
remote: Getting sizes: 100% (4/4)
remote: Compressing objects: 100% (7764/7764)
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://git.overleaf.com/%%%%%%%%%%%%
 * branch            master     -> FETCH_HEAD
   f0173f3..d3bb61b  master     -> overleaf/master
Merge made by the 'recursive' strategy.
 Section2.tex | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)`

I've run into problem now when I need to commit changes and push changes to Gitlab. I get lines such as:

git commit -m "configuring git access, no major edits have been made"
On branch master
Your branch is ahead of 'overleaf/master' by 16 commits.
  (use "git push" to publish your local commits)
nothing to commit, working directory clean

and

git push gitlab
Username for 'https://gitlab.thing.ty':
Password for 'https://[email protected]':
To https://gitlab.thing.ty/folder/note_name.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 

'https://gitlab.thing.ty/folder/note_name.git'

hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

I can't seem to figure out how to manage two different repositories at once.

Answer 1

the repo with the biggest amount of commits should be the one that you pull from before attempting any change.

git pull upstream master

after that make sure your gitlab repo is synced with upstream.

git push origin master

This way both repos are synced while you do your work, if you use

git log you should see something like

commit 798a0433ad807b6127066cac3f6e33d6551ef0d4 (HEAD -> master, upstream/master, origin/master)

This means that both repos are in the same commit.

after doing your work (better if you make it on a separate branch) you need to commit those changes. git commit --all -m "some text"

after doing it you should see with git log that your new branch is ahead from both upstream and origin, if you want to integrate the changes into any of them you should use git rebase, this will make a fast-forward on the repo. We don't use pull because it would melt all the commits while merging them. After that, I'll assume that you don't have write permissions on both repos.

Use git fetch to download the changes from one of the repos, for example git fetch upstream master and after that see the commits with git log then use git rebase to merge the changes in a secure way.

Refer to Git official book for more info, but you should be fine after reading the 3 firs chapters.

Answer 2

There are three general cases for having multiple git remotes, and how you handle things depends on which case you need:

1. You have a fork of some piece of software with your own custom patches on top. This is the most common case I know of, and the only one I've had personal experience with, and is actually a pretty typical situation for development. A really good example of this would be https://github.com/Ferroin/linux, where I maintain a small handful of local patches on top of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
2. You have multiple upstream repositories where you publish work and want them to remain in sync with each other. I don't know of any projects which do this regularly, though it is sometimes done when a project is transitioning between different hosting providers for it's repositories.
3. You have a separate development and release repository. This is pretty similar to case 1, just in reverse.

As mentioned, handling things depends on which case you are in. The simplest situation (and the one I think you're in given the description of your question) is case 2 actually, where management just consists of making sure you push to both repositories when you push updates (git requires you to explicitly push to each remote). Case 3 is pretty easy too, when you make a release, you just tag it and push to both repositories, but only push to your development repository when you aren't releasing something.

Case 1, while the most common, is the most complicated because it involves more than just push and pull commands. The only situation where a secondary remote matters there is when there's an update upstream, at which point you need to pull that and rebase (or merge, depending on your local workflow) your local branch on top of that.

Also, you might be interested in reading the official Git Book, it does a great job of explaining things. The chapter on 'Distributed Git' is probably the most relevant section to this question, but I would absolutely suggest reading the whole thing, as understanding the workflows kind of requires a good understanding of how Git does source control.