4 ms·

> 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,

by jolmg 3mo ago

> 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.

rmunn 3mo ago
Unless E remained untouched because it was not rewritten, and ended up staying parented on B instead of getting reparented onto B'. Which is usually not what you want; most of the time you want E', which is E reparented onto B'. But sometimes you want E to remain untouched and stay parented on the original B. Depends on the situation.
- jolmg 3mo ago
  Exactly, but the second graph where untouched E is reparented to B' is not something that git would allow.
  - shepmaster 3mo ago
    Ah, good catch. That's more of a graphic issue and not what I was trying to express. Updated the OP.
    - deleted 3mo ago
      [deleted]
shepmaster 3mo ago
> Haven't used --update-refs, but reading it, it should result in your third graph. I don't think it does. I tried locally: mkdir test; cd test; git init touch a; git add a; git commit -m 'a' touch b; git add b; git commit -m 'b' touch c; git add c; git commit -m 'c' git checkout -b branched-feature HEAD~ touch d; git add d; git commit -m 'd' git checkout main echo 'change' > b; git add b; git commit -m 'fix b' git rebase -i --root --update-refs And ended up with this graph (`git log --graph --all`) * commit (HEAD -> main) | | c | * commit | | b | | * commit (branched-feature) | | | | d | | | * commit |/ | b | * commit a Replacing the `git commit -m 'fix b'; git rebase -i --root --update-refs` with `git history fixup HEAD~` produces what I'd like: * commit (branched-feature) | | d | | * commit (HEAD -> main) |/ | c | * commit | | b | * commit a
- jolmg 3mo ago
  Huh.. That's a shame :(. Maybe what it refers to is if you had a branch on B rather than D, it might update that. EDIT: Yeah, this seems to be it. `git branch b` on b, then `git rebase -i --update-ref @~3` from main caused branch ref `b` to move from d86229e to 02fcaf7: * 1e354fb (HEAD -> main) fix b * 40e6f70 c * 02fcaf7 (b) b | * f4188e0 (branched-feature) d | * d86229e b |/ * 5fe78fa a
- Izkata 3mo ago
  > And ended up with this graph (`git log --graph --all`) Add --oneline to get the compact version from the other reply.
seba_dos1 3mo ago
It won't result in the third graph on its own as E isn't reachable from D, but it could if you first merged D and E together and then used --update-refs with --rebase-merges. You could then just discard the merged branch and only take care of D' and E' on their own (and since you don't care about the merged branch, you don't have to care about resolving conflicts while preparing it either).

by jolmg 3mo ago

rmunn 3mo ago

Unless E remained untouched because it was not rewritten, and ended up staying parented on B instead of getting reparented onto B'. Which is usually not what you want; most of the time you want E', which is E reparented onto B'. But sometimes you want E to remain untouched and stay parented on the original B. Depends on the situation.

jolmg 3mo ago
Exactly, but the second graph where untouched E is reparented to B' is not something that git would allow.
- shepmaster 3mo ago
  Ah, good catch. That's more of a graphic issue and not what I was trying to express. Updated the OP.
  - deleted 3mo ago
    [deleted]

shepmaster 3mo ago

> Haven't used --update-refs, but reading it, it should result in your third graph. I don't think it does. I tried locally: mkdir test; cd test; git init touch a; git add a; git commit -m 'a' touch b; git add b; git commit -m 'b' touch c; git add c; git commit -m 'c' git checkout -b branched-feature HEAD~ touch d; git add d; git commit -m 'd' git checkout main echo 'change' > b; git add b; git commit -m 'fix b' git rebase -i --root --update-refs And ended up with this graph (`git log --graph --all`) * commit (HEAD -> main) | | c | * commit | | b | | * commit (branched-feature) | | | | d | | | * commit |/ | b | * commit a Replacing the `git commit -m 'fix b'; git rebase -i --root --update-refs` with `git history fixup HEAD~` produces what I'd like: * commit (branched-feature) | | d | | * commit (HEAD -> main) |/ | c | * commit | | b | * commit a

jolmg 3mo ago
Huh.. That's a shame :(. Maybe what it refers to is if you had a branch on B rather than D, it might update that. EDIT: Yeah, this seems to be it. `git branch b` on b, then `git rebase -i --update-ref @~3` from main caused branch ref `b` to move from d86229e to 02fcaf7: * 1e354fb (HEAD -> main) fix b * 40e6f70 c * 02fcaf7 (b) b | * f4188e0 (branched-feature) d | * d86229e b |/ * 5fe78fa a
Izkata 3mo ago
> And ended up with this graph (`git log --graph --all`) Add --oneline to get the compact version from the other reply.

seba_dos1 3mo ago

It won't result in the third graph on its own as E isn't reachable from D, but it could if you first merged D and E together and then used --update-refs with --rebase-merges. You could then just discard the merged branch and only take care of D' and E' on their own (and since you don't care about the merged branch, you don't have to care about resolving conflicts while preparing it either).