git rebase --onto still ends up with the code I'm trying to eliminate

I have some production code that had to be rolled back, because testing that I was told was completed successfully was not done. It was put into production, committed to the master branch, and then was "rolled back" when users discovered the untested bugs.

Note that I normally am the only one writing to this repo, but some changes were done to it while I was on vacation, and I'll admit I've gotten somewhat confused.

In any case, I'm pretty sure I want to rebase my new code against the older, pre-bug, "rolled-back" version of the code, which I believe should be done using git rebase --onto

Several articles have helped me to learn at least something about this (clearly I still have much to learn). The diagramming format you see here is inspired by the more helpful articles I've read.

So, I have the following commits:

    A---B---C---D---E---F---G---H---I

The errors were introduced in the production code from B to E, and I wrote F through I based on this code. So:

    Known good
    |   Buggy and to discard
    |   |               Good and needs to be replayed onto A
    |   |               |
    >   ->              ->
    A---B---C---D---E---F---G---H---I

So that I end up with:

    A---F---G---H---I

Now from all the reading I've done, what I think I'm supposed to run is: git rebase --onto A F I

But when I do that the code I end up with still has all the bad code in it.

So, I'm doing something wrong, but I cannot see what it is.

I have read the following already (which were helpful, but didn't seem to describe my situation precisely) https://medium.com/@gabriellamedas/git-rebase-and-git-rebase-onto-a6a3f83f9cce Git - rebasing to a particular tag https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Maybe I'm doing this all wrong. I want to rewind to the state that production is currently in (the "rolled back" state), and then replay the development I've done onto that. Perhaps there's a better way.

Any and all help, advice, tips, criticisms, places to read more about this, etc., would be very gratefully accepted.

CodePudding user response：

Well, I've certainly learned a few things about git, so that's good.

I could not ultimately make any sense out of this, because what all the documentation and responses said, and what I was experiencing, did not match.

I accept full responsibility for this, but in the interest of time, what I did was to diff all the commits from F to I against A, and then manually add those to A.

Then I had the bright idea to use GitLab because it has a nice interface for merges and diffs, and did a compare of my A-F-I code against B-E, and that was looking good.

So, I forged A-F-I into a new branch, and requested a merge of B-E into it.

Some conflicts, but really nothing too tricky. More importantly, the code all looked the way I would expect; everything was where I wanted it to be.

It's still got to be tested, but I'll just debug from here and manually correct everything.

Thanks all for the advice. You gave me ideas that helped me to make more sense of things, so that was helpful.

I still don't understand what I was doing wrong, but that's OK; learning is like that sometimes. I do feel like my git knowledge has advanced, and, perhaps more importantly for me, I haven't come away with a "don't go there" attitude, which can sometimes happen.

So, that's all for this. Thanks again for taking the time to respond. That meant a lot to me.

CodePudding user response：

The git rebase would actually be:

git rebase --onto A F~ I

You need to take the parent of F as upstream, since a rebase --onto rebase all commits after the specified upstream commit.

So when I rebase interactively, the doc that comes up shows each of the commits I want to include (F through I in my example), and none of the commits I don't want.

That would mean starting from a state where git log does not show

A---B---C---D---E---F---G---H---I

Because if it did, a git rebase -i A should display in its todo list all commits from A up to the current branch (referencing I)
Make sure you are on the right branch before starting said rebase.