Workflow to keep Codeberg fork synced?

Discussion Discuss FreeSewing development & code
1

I don’t see a way to easily update a forked repository on Codeberg, to keep it in sync with the original repo?

On Codeberg, I forked freesewing/freesewing to create my BenJamesBen/freesewing repository, and then I git cloned BenJamesBen/freesewing to a local repository. On GitHub, they have a “Sync” button I could use to keep my GitHub fork synced with the FreeSewing GitHub repo. However, I don’t see a similar button on Codeberg?

As a workaround, with my local repo I:

  • git remote add upstream https://codeberg.org/freesewing/freesewing.git
  • git pull --rebase upstream develop (so, now my local repo is now updated and synced with freesewing/freesewing)
  • git branch --set-upstream-to=upstream/develop develop (so, I think that future git pull will make the local repo in sync with freesewing/freesewing?)
  • git push origin develop (which pushed the synced local repo back up to BenJamesBen/freesewing on Codeberg)

But, is there an easier way to keep my Codeberg fork synced with the FreeSewing repo?

2

What I usually do is just don’t worry about keeping an up-to-date develop branch in my fork.

Whenever I create a new local branch, I just create it from upstream/develop. Or if I need to rebase a branch I rebase it directly onto upstream/develop. And so on.

You just have to call git fetch to keep the upstream remote up-to-date.

Of course your approach works, too. In either case, one could write a simple script that does the same as the sync fork command on GitHub.

3

@Benjamin_F We can configure a push mirror on the repository.
Have never used this, but if you’d like I’m happy to configure your fork (or another test repo) here to see how that might work out.

image
image1794×845 84.6 KB

4

No, it’s okay. If a different workflow works better, is easier, and is more appropriate for Codeberg for all users, then I’ll just change my workflow.

With GitHub, the model I had been using was…

  1. Initially: freesewing/freesewing (fork)-> BenJamesBen/freesewing (clone)-> local repository
  2. Thereafter: freesewing/freesewing <-(PR) (sync)-> BenJamesBen/freesewing <-(push) (pull)-> local repository
    … because GitHub made the sync step easy.

It appears that with Codeberg, the model will need to be…

  1. Initially: freesewing/freesewing (fork)-> BenJamesBen/freesewing (clone)-> local repository
  2. Thereafter: freesewing/freesewing (pull)-> local repository (push)-> BenJamesBen/freesewing (PR)-> freesewing/freesewing
5

My usual workflow for projects like this is to set up the following:

git clone ssh://git@codeberg.org/freesewing/freesewing.git --single-branch to get the default remote set as origin and pointing to freesewing, but only the default branch (in this case develop)
fork the repo in codeberg (usually also only picking the default branch but it doesn’t really matter)
git remote add ephphatha ssh://git@codeberg.org/ephphatha/freesewing.git to put a reference to my fork in the local git instance
git config --local --set remote.pushdefault ephphatha so any new branches I create will get pushed to my fork instead of attempting to go to the origin.

Then I just need to remember to switch to develop, pull, create a new branch for my changes (and switch to it), then push will default to doing the right thing.

2 Likes