4 ms·

You can rebase, but you're still: - Creating a false history that will be harder for you to understand in the future - Creating a history that tools will have

• 000ooo000 2y ago
  I ranted about this in another comment in this thread, but what do you mean by rebase here? Reworking commits? Squashing commits?
• dahart 2y ago
  There’s no such thing as false history in git. Git was not designed to provide an audit trail of keystrokes, and as you can see from the larger comment thread here: nobody needs that. Git provides a mechanism for establishing and rearranging commit dependencies. The order of commit dependencies can be changed by design. You are factually incorrect about rebase making things harder for people or tools to understand. The primary use case for rebase is making things easy to understand, in private branches after liberal use of the ‘commit early; commit often’ rule. If you take rebase away from git, and ask people to be okay with commits becoming immediately permanent, you increase the chances that people will make mistakes or lose work before they commit, and you remove some flexibility of being able to work on multiple separate topics in a single branch. Like any and all tools, rebase can be used incorrectly, but it is not used incorrectly most of the time, and basing your argument on the rare accidents means the argument is straw man.