> One reason you don't want to see everything you've ever written is because it is wrong, or maybe you changed your views in the process of writing, or no longer important to the point you're making.
I'm not necessarily disagreeing with the main point, but all of these things happen with code too. I've had to counsel people before who were scared to commit code until it was perfect, and I've had to try and push into their head that it's not bad to have Git commits that they aren't proud of. Part of breaking them of that habit was teaching them to be OK with allowing people to see their bad code and bad ideas, but another part of it just came down to teaching them how `rebase` works.
On the text side of things, I already publicly commit any edits I make to blog posts, documentation, and any websites I make after publishing -- even if they're embarassing. Occasionally I'll also publish rough drafts if they're not sensitive content. Part of that is getting over the fact that people might see bad writing. If I was worried about people seeing my bad ideas, I wouldn't publish anything in the first place. 10 years from now, I hope that I'll have matured enough that I can look back at my blog and be embarrassed about some of my writing. If I don't have anything to be embarrassed about, I probably haven't grown much as a person.
But of course, for particularly sensitive or complicated topics I generally don't push rough drafts. And that's where rebasing comes in. Version/edit tracking isn't just about public transparency. Even with sensitive topics, I still put rough drafts of blog posts in local branches and commit edits while I'm building them. My workflow with private and public content is exactly the same. It's just that when I eventually push to a public repository, I first squash the branch down into a single commit.
Transparency with edits is relevant to me because edit history is a personal/org-wide organizational tool. Those edits don't need to be pushed to the public, sometimes they don't even need to leave my computer, but sometimes I like to look over my writing and see how a site/post/article has evolved.
History isn't necessarily static. It's very common in version control to rewrite history when needed, and to push different parts of history to different remotes where people have different levels of access.
I'm not necessarily disagreeing with the main point, but all of these things happen with code too. I've had to counsel people before who were scared to commit code until it was perfect, and I've had to try and push into their head that it's not bad to have Git commits that they aren't proud of. Part of breaking them of that habit was teaching them to be OK with allowing people to see their bad code and bad ideas, but another part of it just came down to teaching them how `rebase` works.
On the text side of things, I already publicly commit any edits I make to blog posts, documentation, and any websites I make after publishing -- even if they're embarassing. Occasionally I'll also publish rough drafts if they're not sensitive content. Part of that is getting over the fact that people might see bad writing. If I was worried about people seeing my bad ideas, I wouldn't publish anything in the first place. 10 years from now, I hope that I'll have matured enough that I can look back at my blog and be embarrassed about some of my writing. If I don't have anything to be embarrassed about, I probably haven't grown much as a person.
But of course, for particularly sensitive or complicated topics I generally don't push rough drafts. And that's where rebasing comes in. Version/edit tracking isn't just about public transparency. Even with sensitive topics, I still put rough drafts of blog posts in local branches and commit edits while I'm building them. My workflow with private and public content is exactly the same. It's just that when I eventually push to a public repository, I first squash the branch down into a single commit.
Transparency with edits is relevant to me because edit history is a personal/org-wide organizational tool. Those edits don't need to be pushed to the public, sometimes they don't even need to leave my computer, but sometimes I like to look over my writing and see how a site/post/article has evolved.
History isn't necessarily static. It's very common in version control to rewrite history when needed, and to push different parts of history to different remotes where people have different levels of access.