4 ms·

> Is laughably incorrect It depends on your workflow. It's correct in context. Don't rebase. You see the commit that caused the breakage if you have a testsuit

• golergka 11y ago
  But you will have to either merge or rebase if someone else pushed into master while you were working. The difference is, rebase keeps the history honest about the fact that you were working concurrently, while rebase tries to construct an alternate, false version of these events.
  • yxhuvud 11y ago
    The interesting part of a commit is not when you did something, but how it will change the repository.
    • Pyxl101 11y ago
      Rebase also doesn't change when you did something either.
    • golergka 11y ago
      But "how it will change the repository" depends on "when" did you change something, e.g. parent commit.
      • yxhuvud 11y ago
        Yes, which is why you want a straight history so that it is obvious that no shenanigans had to happen in the merge commit.
  • jack9 11y ago
    > rebase keeps the history honest The history is a record of changes. You're suggesting there's a good reason to track timeshifting by implication (you could rebase at multiple points) because...honesty? I'm not trying to argue about the why. I'm trying to understand the why. My view is that you merge your change into the head and there's a record. That's the story. The particulars of how a particular commit came to be is irrelevant to the repo and less problematic when it's treated the same as any other commit.