Guido,
Am 06.10.21 um 16:38 schrieb Guido Günther:
I've currently decided against this option because to keep the existing old history within the same tree as base for the current new added branch.
…but that wouldn't change since the current history is on `master` and you'd merge that plus your changes / the update into `pureos/latest`, right?
no, my current way of doing nor your point would break or drop history, how you are seeing it, or your pov of doing is just another way to get the same goal. The merge of the old master branch is just into another direction than I've done it currently.
Am i missing something? Your merge of the old 'master' wouldn't get broken as long as the merge of the MR to `pureos/latest` is fast-forward.
Sure, to get things merge-able by a MR the repo on core-packages would need an existing branch pureos/latest. That isn't existing right now.
I've tried the readjust the way you would make update for the fork.
1. Create new branch pureos/latest based on Debian tag 2.93 2. Merge in the (old pureos) master branch 3. Add additional stuff as gbp.conf and CI yaml file
The outcome and the required work is the same to my current kind of doing, most of the work is to solve the merge conflicts as this is exact same todo on both ways.
But maybe I'm the one that is missing something. ;)
Again I have no strong opinion here but rather try to understand why one would use a different workflow as with other packages (which e.g. results in the discussion being split between mailing list and giltab).
Well, the thing is still, there is no branch I can start a MR against (at least I think). There is not even yet a tag 2.93 on soure.p.s., there is currently only the old master branch which isn't connected anyhow to the "mother" tree on Salsa. If it would exist at all this mail traffic wouldn't needed and I've started directly any discussion within a MR.
If the outcome is there is no problem to create a starting branch pureos/latest by preparing the tree on source.p.s then I'm of course fine with this. I'm unsure if I would can do that, given to the permissions for Developers I should.
My take for using merge requests for about everything is that it keeps the discussion close to the code (and searchable).
I fully understand this. But I'm quite conservative about possible direct action on "hot" repositories as I'm still new and like to prevent any damages.