3 ms·

What I would do in this case is two rebase -i. Say you start from: A B And you want: state-of-B state-of-A I'd do a rebase -i with: pick A x gi

What I would do in this case is two rebase -i. Say you start from: A B And you want: state-of-B state-of-A I'd do a rebase -i with: pick A x git revert HEAD pick A pick B Let's call the resulting commits of the above a, b, c and d. With the following rebase -i, you get what you want: pick a squash d pick b squash a In practice, I just do git revert HEAD; git cherry-pick HEAD~ before working on B, so I only really do one rebase.

kazinator 5y ago
Problem is, you may get ugly conflicts along the way which serve no purpose to the end goal, and have to be resolved more than once in different directions. It's an abstraction inversion to be doing that. The system doesn't work with diffs and merges: that's just layering on top. The system contains snapshots, and so if you want to rearrange snapshots in a different order, that's the best abstraction layer to work at.
- glandium 5y ago
  Oh, I actually messed it up. Which in hindsight I don't know why because it's really much simpler than what I started with... but then I usually do it with more intermediate steps, and on an actual command line, not on a mobile phone... Anyways: You start with: original-state A final-state B intermediate-state You want original-state X intermediate-state Y final-state What you just need to do is: git revert HEAD Which gives you: original-state A final-state B intermediate-state revert (C) final-state Then X = A + B and Y = C, so with one rebase -i: pick A squash B reword C No conflicts. The important thing is that with appropriate reverts and reapplication of commits, you can make your history contain the states you want in the order you want, even if in between you have repeated states in the wrong order. Then you squash things so that you only keep the states you wanted in the first place. Edit: but yes, you can achieve the same outcome with read-tree or checkout. Edit2: come to think or it, you can probably do what you want with a couple git replace --graft and a noop filter-branch.

kazinator 5y ago

Problem is, you may get ugly conflicts along the way which serve no purpose to the end goal, and have to be resolved more than once in different directions. It's an abstraction inversion to be doing that. The system doesn't work with diffs and merges: that's just layering on top. The system contains snapshots, and so if you want to rearrange snapshots in a different order, that's the best abstraction layer to work at.

glandium 5y ago
Oh, I actually messed it up. Which in hindsight I don't know why because it's really much simpler than what I started with... but then I usually do it with more intermediate steps, and on an actual command line, not on a mobile phone... Anyways: You start with: original-state A final-state B intermediate-state You want original-state X intermediate-state Y final-state What you just need to do is: git revert HEAD Which gives you: original-state A final-state B intermediate-state revert (C) final-state Then X = A + B and Y = C, so with one rebase -i: pick A squash B reword C No conflicts. The important thing is that with appropriate reverts and reapplication of commits, you can make your history contain the states you want in the order you want, even if in between you have repeated states in the wrong order. Then you squash things so that you only keep the states you wanted in the first place. Edit: but yes, you can achieve the same outcome with read-tree or checkout. Edit2: come to think or it, you can probably do what you want with a couple git replace --graft and a noop filter-branch.