Hi all,
It seems that the current master is not in very good condition for active binding development but unfortunately I’ve rebased 3 of my branches on it instead of on top of 2.5.x branch. Two of the branches have small feature increments that I could push into 2.5 branch. The third will probably wait for 3.x…
Is there any way to “easy” move these branches back to 2.5.x? I’ve read that cherry pick is my best bet but problem is that some conflicts due to the rebased changes occur. I guess I need to resolve them for every commit if I cherry pick all my commits, right?
Try using git cherry-pick to move commits alone. If you are more interested in moving back to state before rebase then git reflog is your friend. It will give you list of states registered internally in SCM repository. Once you find stage which is valid for you do git checkout -b test 887291c or, if you are brave enough, git reset --hard 887291c.
You can check description of these commands/actions in git manuals.
Another option is to remove all commits between your commits on the timeline to before the point on the timeline where the 2.5.x branch was created. You can do this with: git rebase -i HEAD~10 where 10 is the number of commits you want to go back. This can be a arbitrary number and you can repeat this process. The interactive rebase will open an editor with the commit hash and a command option per line. Replace pick with d (for delete) for all previous commits you want to remove. Save the file and exit and it will remove the commits. Your basically doing a reverse rebase. Repeat this process until your commits are based on a commit before the branch 2.5.x was created (the actual point doesn’t matter) and then do a new git rebase on the 2.5.x branch.
Thanks to both of you !
I think I got it right with interactive rebase for the two smaller branches.
I wonder if there is bigger code-change (the encryption support for the binding) will it has place into 2.5.x branch or I need to wait for 3.0? I had to refactor a lot of code during this development, also saw couple of bugs which is good to be fixed. I guess it’s not a good idea to have some feature fragments (like the encryption) in 3.0 and some in 2.5 (like the smaller features) and then merge them at some point in time. Best would be to all go in a chain even if they’re in 2.5 branch and maybe migrate from there once 3.0 is ready. Is that right?
