I’m facing a weird issue with Git, that I’ve also asked on Stack Overflow. This one is a cross post. Original SO link can be found here: https://stackoverflow.com/questions/60381936/git-rebase-with-pause-after-every-commit
Now, let me also copy it here for context:
Let’s say that we have two versions of a library X: v1 and v2
I’m a maintainer for another library Y which uses library X. I was using v1 of the library, and it is there in master.
Then library X has come up with a new version v2, which required me to change the way I use the library (only package changes, library X changed it’s name). Version v1 is now deprecated.
However, because my library is currently being used by enterprise users, who are not willing to update to a newer version of my library that uses v2. Also I’m supposed to provide fixes to the old version by contract.
I had two branches now:
[]master (uses v1)
[]new_master (uses v2)
The way I made this change is by developing on master, and rebasing new_master onto master. Then I can have one commit which contains changes that change all the v1 packages to v2 packages (import lines are the only changes).
master x----x----x----x----x----n
new_master x----x----x----x----x----f
(after rebase)
master x----x----x----x----x----n
new_master x----x----x----x----x----n----f
Now, I added a new feature to my library, which needs v2 of the library X. So it will only exist in new_master. After adding the new feature, the tree became like this.
master x----x----x----x----x----x----n
new_master x----x----x----x----x----x----f----n
I can do the same rebase here, but the commit n in the master tree needs to be fixed also. I don’t want to add one more fix after the n of new_master.
What I get if I do a regular re-base:
master x----x----x----x----x----x----n
new_master x----x----x----x----x----x----n----f----n----f
Second f is the new fix commit, because after second n commit, branch new_master fails to compile.
What I need to get:
master x----x----x----x----x----x----n
new_master x----x----x----x----x----x----n----F----n
Where commit F is the new fix commit.
What am I currently doing to achieve this?
[]I’m solving this, by creating a new branch called new_master2 from new_master, then removing the new feature there.
[]Then I’m rebasing new_master2 onto master.
[]The commit for the new feature is lost, so I’m cherry-picking it from new_master.
[]Finally I delete the new_master branch, and I rename new_master2 as new_master.
[*]I finish this by doing a force push to the remote.
What I’m trying to do?
Find another way to do the same thing, without creating the temp branch new_master2.