How to cherry pick?

[Lone_Wolf]

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 .

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.

[mcarans]

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 .

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.

I would say getting the changes from 1.92-maintenance to master is becoming a blocker to any further development. What is left to do on testing cherry picking?

[Lone_Wolf]

Conflict resolution and whether that's different between merge and cherry-pick .

I kinda expect both will require the same manual adjustments .


EDIT

New repo created from oolite on github with 2 copied branches : master & 1.92-maintenance and 2 new ones : cherry & merge
To avoid issues this is not a fork but a separate repo on sourcehut .

see https://git.sr.ht/~lone_wolf/oolite-port/refs

[Lone_Wolf]

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.

[mcarans]

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.

Ok no problem. I will try to do it as a merge in a fork, resolve all the conflicts and then submit a PR. This way I will be able to check I've not missed anything using my now closed PR (which wasn't a merge but just a set of file changes) as a working reference.