-1

I don't know if this is the right way to accomplish what I need and maybe has also been asked a lot, although I couldn't find a solution.

I have mirrored a repository into my Gitlab account via

git clone --mirror https://github.com/some/repo
git remote rename origin upstream
git remote add origin git@gitlab.com:user/my-repo.git
git push origin --all

Now I want to frequently get the changes from the upstream repository without using git pull or git merge, because I want the commits to be identical to the upstream branch and not "Merging upstream into origin..." commits. From what I understand, you need to

cd my-repo
git remote add https://github.com/some/repo
git checkout branch_name
git pull --rebase upstream branch_name  <-- pulls the changes without merging them
git rebase                              <-- rebases to the fetched changes so my own changes will stay on top

This works if I do it manually for the branch, but if I want to iterate through all branches with. Please correct me if I am approaching this the wrong way!

for branch in $(git for-each-ref --format='%(refname)' refs/remotes/origin); do branch=${branch##*/}; echo "\nUpdating $branch..."; git checkout $branch; git pull --rebase upstream $branch; git rebase; done

it doesn't work and the local branches stay untouched.

I know that Gitlab provides its own mirroring tool, but it is not activated in our company.

neolith
  • 699
  • 1
  • 11
  • 20
  • 2
    Please clarify what do you exactly mean by "it doesn't work". What's the output or the error you get? – zaibaq Mar 25 '22 at 15:10
  • 1
    Note that `${branch##*/}` strips all but the final component from a file name. But remote-tracking names are not file names and this is not appropriate in general: for instance, `origin/foo` becomes `foo`, which is OK, but `origin/feature/bar` becomes `bar` which is not. – torek Mar 26 '22 at 01:43
  • 1
    Besides this, it's not at all clear to me whether you *want* to use rebase here for every case. For instance some Git-repository-for-Git branch names are deliberately "rewound and rebuilt", which requires discarding some commits that you had gotten previously from the Git-repository-for-Git. Using rebase could preserve them instead of discarding them (details will depend on `--fork-point` and reflog expiration times). – torek Mar 26 '22 at 01:46
  • @zaibaq It doesn't work means the new commits are not showing in the log when using the for loop. – neolith Mar 26 '22 at 11:14
  • @torek: I did that because when I use the full path, git is checking out some commit hashes instead of the branch. I didn't understand that, so I didn't like it. – neolith Mar 26 '22 at 11:15
  • @torek: So how do you normally do it? Should I merge? I just want the best way to mirror a repository and get the updates from that repo on a daily schedule. I have been googling for this, but I couldn't find a good solution to just keep a clone of a repo. – neolith Mar 26 '22 at 11:16
  • If you want a *mirror* (slaved to the original), use `git clone --mirror` to make a bare mirror clone. Then run `git remote update` or `git fetch` in that bare mirror clone and it's updated. Never do any new work here as it will be lost (overwritten) by a `git fetch` or `git remote update`. But if you don't want this kind of carbon copy—if you ever want *new* commits that someone else doesn't have—mirror clones aren't the right idea: you just `git fetch` their commits into remote-tracking names and then work with those as needed. – torek Mar 26 '22 at 19:37
  • @torek: Well that is how I initially created the repository. It results in a folder named ``my-repo.git``, but when I push that to my Gitlab account, I can only do this once. When I fetch the new updates into the folder, I can't push again. So this has do be accomplished differently somehow. – neolith Mar 28 '22 at 08:26
  • You should be able to push again if you want; just remember that you need to specify the right refspec (or use `git push --all` which supplies the right refspec and adds pruning), and remember that a mirror never holds any commits that aren't in the original repository, which means you can never add your own stuff to it. – torek Mar 28 '22 at 19:48
  • @torek: Yes that is exactly what I want. I will try this out. – neolith Apr 01 '22 at 08:47

1 Answers1

1

This seems to me to be a misunderstanding of what a branch is and what it's for. You should not have any local branches corresponding to the upstream. Just git fetch and stop; you are now mirrored and up to date.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • Maybe I wasn't entirely clear. I want to pull the changes from one remote branch and push it to another. I don't believe fetching is sufficient here – neolith Mar 28 '22 at 08:22