3 ms·

Warning: When I made this comment, I was under some false assumptions. Here's the original. --- A snapshot is the aggregate of all previous changes. I don'

Warning: When I made this comment, I was under some false assumptions. Here's the original. --- A snapshot is the aggregate of all previous changes. I don't see what could be broken by copying the snapshot. I'm not familiar with rebase-pull, but I don't see why any revert would be involved. The snapshot before the rebase is exactly the same as the snapshot after the rebase. Only the predecessor is changed. The contents of the predecessor doesn't matter, since a snapshot contains the entire state of the tree.

masklinn 6y ago
> A snapshot is the aggregate of all previous changes. I don't see what could be broken by copying the snapshot. If you copy the snapshot, you lose all the intermediate commits you're rebasing onto, because they're not in the snapshot you're rebasing. > The snapshot before the rebase is exactly the same as the snapshot after the rebase. Which is exactly what you do not want. > The contents of the predecessor doesn't matter, since a snapshot contains the entire state of the tree. Which, again, is exactly what you do not want: a - b - c - d \ e - f If I rebase `d` onto `f`, I want the changes performed by `e` and `f` as well as those performed by `d`. If I just copy over the `d` snapshot to d', I get the exact same state I had at `d` with a different history, losing the changes performed in e and f, thus reverting them. That's why when you rebase a commit, not only does the commit id change (makes sense, different parent) the tree also changes, which also makes sense because the content changes.
- recursive 6y ago
  Ok I see. I actually misunderstood what rebase actually did. So I guess it's a good thing then that I've never used it. Thanks for your persistence.
  - jfengel 6y ago
    Rebase is useful for artificially straightening out simultaneous work. It's less clear in the above example, where d is just a single commit. But if there's a d1--d2--d3--d4, it can be confusing to merge chronologically (d1--d2--e--d3--f--d4). If there aren't any conflicts, it's conceptually simpler in the long run to rebase it as e--f--d1--d2--d3--d4. You artificially serialize the work, which isn't what actually happened, but it could have happened that way. When you go back and look at it, pretending that it did is simpler. For example, if you have to go back and debug something that happened while working on d1...d4. It's not absolutely mandatory to learn about it. But it the simple cases are common enough, and useful enough, that it's worth learning.
  - pjc50 6y ago
    That didn't stop you from arguing that it was trivial upthread...
    - recursive 6y ago
      I was attempting to answer a question. It wasn't my intent to pose an argument.

masklinn 6y ago

> A snapshot is the aggregate of all previous changes. I don't see what could be broken by copying the snapshot. If you copy the snapshot, you lose all the intermediate commits you're rebasing onto, because they're not in the snapshot you're rebasing. > The snapshot before the rebase is exactly the same as the snapshot after the rebase. Which is exactly what you do not want. > The contents of the predecessor doesn't matter, since a snapshot contains the entire state of the tree. Which, again, is exactly what you do not want: a - b - c - d \ e - f If I rebase `d` onto `f`, I want the changes performed by `e` and `f` as well as those performed by `d`. If I just copy over the `d` snapshot to d', I get the exact same state I had at `d` with a different history, losing the changes performed in e and f, thus reverting them. That's why when you rebase a commit, not only does the commit id change (makes sense, different parent) the tree also changes, which also makes sense because the content changes.

recursive 6y ago
Ok I see. I actually misunderstood what rebase actually did. So I guess it's a good thing then that I've never used it. Thanks for your persistence.
- jfengel 6y ago
  Rebase is useful for artificially straightening out simultaneous work. It's less clear in the above example, where d is just a single commit. But if there's a d1--d2--d3--d4, it can be confusing to merge chronologically (d1--d2--e--d3--f--d4). If there aren't any conflicts, it's conceptually simpler in the long run to rebase it as e--f--d1--d2--d3--d4. You artificially serialize the work, which isn't what actually happened, but it could have happened that way. When you go back and look at it, pretending that it did is simpler. For example, if you have to go back and debug something that happened while working on d1...d4. It's not absolutely mandatory to learn about it. But it the simple cases are common enough, and useful enough, that it's worth learning.
- pjc50 6y ago
  That didn't stop you from arguing that it was trivial upthread...
  - recursive 6y ago
    I was attempting to answer a question. It wasn't my intent to pose an argument.