Rebase doesn't re-apply commits that have already been applied in the new base -- here, it's your append abc change. It's already in the master history. This is so often right that git does this without comment. It's arguably at least worth mentioning in the presence of subsequent reverts.

To see whether anything you're rebasing is already part of the new base history (master, here),

git log --oneline --cherry ...master 

and look for =-marked commits. Those are commits in master that match commits in your branch; rebase won't re-apply them. Swap master... for ...master to see the local equivalents.

If you want an effectively blinded rebase, you can do it with

git checkout -B A master git cherry-pick ..A@{1} # < added the very important `..` by edit 

which just moves A onto master and then cherry-picks everything you just left behind.

Rebase doesn't re-apply commits that have already been applied in the new base -- here, it's your append abc change. It's already in the master history. This is so often right that git does this without comment. It's arguably at least worth mentioning in the presence of subsequent reverts.

To see whether anything you're rebasing is already part of the new base history (master, here),

git log --oneline --cherry ...master 

and look for =-marked commits. Those are commits in master that match commits in your branch; rebase won't re-apply them. Swap master... for ...master to see the local equivalents.

If you want an effectively blinded rebase, a first cut is

git checkout -B A master git cherry-pick ..A@{1} # < added the very important `..` by edit 

which just moves A onto master and then cherry-picks everything you just left behind. To ignore merges (which you probably should), add --no-merges to the cherry-pick, it turns out when you ask cherry-pick for a series it just passes the whole set to git rev-list so you can use the machinery directly:

git cherry-pick --no-merges ..A@{1} # just learned now that cherry-pick takes this 

Rebase doesn't re-apply commits that have already been applied in the new base -- here, it's your append abc change. It's already in the master history. This is so often right that git does this without comment. It's arguably at least worth mentioning in the presence of subsequent reverts.

To see whether anything you're rebasing is already part of the new base history (master, here),

git log --oneline --cherry ...master 

and look for =-marked commits. Those are commits in master that match commits in your branch; rebase won't re-apply them. Swap master... for ...master to see the local equivalents.

If you want an effectively blinded rebase, you can do it with

git checkout -B A master git cherry-pick A@{1} 

which just moves A onto master and then cherry-picks everything you just left behind.

Rebase doesn't re-apply commits that have already been applied in the new base -- here, it's your append abc change. It's already in the master history. This is so often right that git does this without comment. It's arguably at least worth mentioning in the presence of subsequent reverts.

To see whether anything you're rebasing is already part of the new base history (master, here),

git log --oneline --cherry ...master 

and look for =-marked commits. Those are commits in master that match commits in your branch; rebase won't re-apply them. Swap master... for ...master to see the local equivalents.

If you want an effectively blinded rebase, you can do it with

git checkout -B A master git cherry-pick ..A@{1} # < added the very important `..` by edit 

which just moves A onto master and then cherry-picks everything you just left behind.