> That last part goes further than git rebase --update-refs, which only moves refs sitting inside the range you’re actively rebasing. git history instead finds and rewrites every local branch descended from the commit (while also having an option to limit it to only the current branch).
I'm reading that to mean that when I use `git rebase --update-refs` in this situation, where I've currently checked out `D` and update `B` to `B'`:
A ──► B ──► C ──► D
│
└───► E
I'll end up with this state, where `E` remains untouched? A ──► B' ─► C' ─► D'
│
└───► B ──► E
(EDIT: Originally I had `E` point to `B'`, which doesn't make sense)If I use `git history fixup`, it would also update `E` and end up with this?
A ──► B' ─► C' ─► D'
│
└───► E'
If that's the case, is there a way to get `git rebase` to have the same behavior? I've got decades of `git rebase` burned into my fingers at this point.> I'll end up with this state, where `E` remains untouched?
Can't, because a commit's hash takes into account the parent hashes.
Haven't used --update-refs, but reading it, it should result in your third graph. So,
> is there a way to get `git rebase` to have the same behavior?
is already the case.
off-topic, but that is a very clear readable comment you left with those line-drawing characters.
See: https://blog.hot-coffee.dev/en/blog/git_update_refs/