Unclear rebase vs. merge analogy

[Daniel-Hug]

From the third paragraph under "rebase vs. merge" in chapter 3.6:

The opposing point of view is that the commit history is the story of how your project was made. You wouldn’t publish the first draft of a book, and the manual for how to maintain your software deserves careful editing. This is the camp that uses tools like rebase and filter-branch to tell the story in the way that’s best for future readers.

This doesn't make sense to me, especially the second sentence.

[YueLinHo]

Why? Does the story of how your project was made confuse you?

[ben]

Well, I understand that this just isn't cutting through for you, and that's fine. Can you think of a better way to phrase it? I'd love to make this section useful for more people.

[Daniel-Hug]

I think perhaps it's just the run-on sentence that is confusing.

How about this?:

You wouldn’t publish the first draft of a book. For the same reason, the manual for how to maintain your software deserves careful editing.

Is the commit log really "the manual for how to maintain your software" though?