Bug 444138

Can you please provide background to what you are trying to achieve here?

I did fork and clone several projects to study its source code and implement features locally and test them inside containers. For feature proposals I would like to do merge requests of certain feature-branches. To prepare the branch as conflict-free as possible, I thought a cron mirroring of my forked master branch useful.

Assuming these are personal forks of other projects on invent.kde.org, then you should simply be able to fetch those into your local clone, rebase your branch as needed and then push it back up to your private fork.

The push shouldn't require much data to be transferred as the server will automatically provide those from the upstream repository on our side.

The system cannot rebase for you (as the changes may need human intervention) which is what any mirroring system would need to do.

Right, but actually I didn't assume that mirroring will provide automatic conflict solving.

The strategy is to fork a project, mirror the master branch from upstream on a regular basis, implement new features on feature-branches, merge back to private fork master, and finally file a merge request upstream. The mirroring step just prevents me from missing any conflicting upstream changes.

There is also a gitlab article explaining the issue: https://about.gitlab.com/blog/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/

I'm not sure you need to have a clone in invent.kde.org to study a project, and I'd always promote working with whichever upstream at hand.

Which projects are we talking about that won't allow you to do that in their infrastructure?

@Aleix Right, studying a project does not need any fork at all.

I assumed that's the way to go because there are tons of probably outdated forks on invent. So you promote the strategy to clone original, branch feature locally, push branch upstream, and finally file a merge request without forking at all?

Oh you mean within our organization?

That's how most of us have been working. The branch you want to have reviewed, you should have rebased against origin/master anyway. You can push it to your clone in a branch too, it's you keeping it fresh regardless of where your branch lives.

@Aleix without cron mirroring the fork I'd rather add and fetch a remote "upstream", rebase upstream/master and push origin master.

The thing is, if an organizational vector touches several integral kde projects (in a modular way of course) and probably takes lots of local research and testing, I think its better to have relevant up-to-date forks, which keeps the concept/usecase/showcase isolated first. Thats the case if a feature is complex, and one has no interest in discussing/arguing every single merge or something.

My aim is to show usecases of rdf, nepomuk/baloo, akonadi, kraft, calligra/kile, freecad (bim/ifc), kplan inside a custom arch distro. If the usecase/concept is actually useful I could propose/file merge requests upstream to kde.

So I am currently planning a continous integration across arch build system, kdesrc-build and custom distro build system, containerized testing with buildah/podman/nspawn.

Mirroring the fork's master just seemed to be useful, to get rid of the local upstream rebase.

Sorry i'm still a little confused here as to how mirroring fixes your issue.

If there are no changes required, then a fork shouldn't need to be created and you can just use the original upstream repository.

If changes are required, then your repository would need to be rebased, which is something only a human can realistically do (in case of conflicts, etc). The only thing I see that mirroring would help with is that it would save you having a separate remote and running "git fetch" in your local copy.

Unless i've missed something here?

As far as I understood the mirroring-feature, it just does mirror the upstream master branch hourly/daily/weekly into my fork master branch, no matter what, like a hard reset. So everything I merge into my own fork master will be lost.

But if I merge the regularly updated fork master into my fork feature branch, I can solve possible conflicts with latest master on my own, and finally file a merge request upstream. So upstream developer receives a conflict free merge with high probability.

Maybe I got something wrong with the mirror-feature's purpose anyway. possible of course. even likely.

My understanding of Gitlab's mirroring functionality is that it works by creating an exact replica - any branch or tags you create that don't exist upstream will be erased by it.

We have custom tooling that supports the KDE Patchset for Qt for this very reason.

Created attachment 142801 [details]
gitlab mirror settings

@Ben thats the default behavior I guess. But in recent years several gitlab clients/users asked for additional options, which can be useful for distributed development.