Oolite Bulletins

$ git clone https://github.com/OoliteProject/oolite
$ git checkout 1.92-maintenance
$ git switch master
$ git remote set-url origin [email protected]:~lone_wolf/repo-name    # replace with correct name
$ git push

$ git branch new-branch 
$ git switch new-branch
$ git push

mcarans wrote: ↑Thu Mar 26, 2026 12:35 am

I don't think I've seen a project where people give commit by commit descriptions of what is merged from one branch into another: people generally highlight the salient changes so that future developers can tell the wood from the trees. Then if developers want to know more, they delve into the code changes in the PR.

Lone_Wolf wrote: ↑Thu Mar 26, 2026 9:51 am

I've figured out what went wrong and now use these commands to prepare everything :

Code: Select all

$ git clone https://github.com/OoliteProject/oolite
$ git checkout 1.92-maintenance
$ git switch master
$ git remote set-url origin [email protected]:~lone_wolf/repo-name    # replace with correct name
$ git push

$ git branch new-branch 
$ git switch new-branch
$ git push

This is easy to replicate and ensures everything is done without consequences for upstream.
I will try merging , but expect conflict resolution will require creating patches for individual commits.

I think that doesn't match well with merging and is likely to end in a massive patch to solve the conflicts (similar to the commit you created) and make it harder to verify the changes/troubleshoot .

mcarans wrote: ↑Thu Mar 26, 2026 12:35 am

I don't think I've seen a project where people give commit by commit descriptions of what is merged from one branch into another: people generally highlight the salient changes so that future developers can tell the wood from the trees. Then if developers want to know more, they delve into the code changes in the PR.

I will keep the analysis & commands used out of the new repo.

Lone_Wolf wrote: ↑Sun Mar 29, 2026 4:42 pm

git merge doesn't seem to be able to start merging at a specific point.
It looks for the common ancestor between the branches and starts there.

I think that works great if one of the branches didn't get commits after that common ancestor or they change different parts of the sourcecode.

With 2 branches that changed the same files as we have here imo the differences are to big to solve them by using git merge.

Git cherry-pick does allow to focus on commits , unfortunately solving the conflicts requires good insight in what the commits do .

compare installers/flatpak/create_flatpak.sh and installers/flatpak/space.oolite.Oolite.yaml from master branch with the state after applying https://github.com/OoliteProject/oolite ... 5ad7d14fdc .

The differences are so big I have no idea how to solve that conflict.

Atm oolite appears to have 2 versions that deviate a lot from each other, 1.92-maintenance and master .
I'm afraid the conflicts can only be solved by those that wrote the commits involved and I have no idea which would be easier :
port commits from master to 1.92-maintenance (and make the updated 1.92-maintenance the new master) or the reverse.

Sorry people.