[WhatsName]

Yes, I do the same. When I develop stuff, I tend to move quick and break things, which might involve swearing in git commit messages or just being plain stupid. I also have a habit of commiting sensitive information like host names, passwords or API-keys to private github repos, thinking not much about it.

If you take your scratch project to opensource, you typically don't have the time to make sure not only the current version, but also every intermediate result is free of flaws someone else might dig up.

So: mv private opensource; git init; git remote add ...; git push

An artist also wouldn't hang every draft drawing beside his gallery piece...

[imiric]

That is a terrible practice. The point of a commit history is to see the development progress, document why a change was done, and in the future be able to reference or revert a change. If you squash all of it before making it public you rob yourself and any future contributors of those abilities.

I also "move quickly and break things" when prototyping, but always go back and clean things up so that each change is atomic and well documented. In practice, this is not a perfect process, but being disciplined about this is worth it. Otherwise, you might as well not use version control at all.

This is also my argument against squashing PRs into a single commit (unless it's really a single isolated change). Sure, it's convenient to do so, and you end up with a "clean" history, but having granular changes is worth the time and effort, and it's something you should strive to do in general.

[2024throwaway]

Open source maintainers don’t owe you the ability to see development process before the project was open sourced.

Squashing PRs is correct. Why would you need to see the hundred commits that lead to one working set of changes. The final changes are all that matter.

[imiric]

Making a project open source is an invitation for anyone to use, change and contribute to it. Purposefully hiding the history of how it was built makes the work of not only future contributors, but of the original maintainer, more difficult. If someone wants to remove a feature, they need to cherry-pick it manually. If an experiment was done early on during prototyping and was scrapped, this information is lost. If someone wants to know why a piece of code exists, this information is lost.

Keeping a clean history of incremental atomic changes is the entire purpose of using version control. It's not just common courtesy that I as an entitled user feel like I'm "owed".

The same applies for PRs, but I won't get into it any further.

I feel like there's a vocal segment of developers who don't understand the benefit of atomic commits, and by extension, version control, and are strongly opinionated in favor of the lazy approach. Working with someone like that can be a frustrating experience.

But please continue to downvote me because you disagree. :)

[LeafItAlone]

To be honest, opinions like these are why it’s so draining to be an open source maintainer.

Some open source projects are just that - open source. You get the source and nothing else. You are not owed anything and you are not invited to collaborate and contribute. And that’s fine. Fork it and do things your way.

The community would be much more pleasant and healthier if casual passersby were not demanding things be done a certain way without actually caring about or contributing.

[imiric]

This goes beyond open source, though. Someone doing this would act the same way when working in a team in a closed source project as well. I'm just saying that it's unacceptable in either case.

Open source is about fostering a spirit of sharing and collaboration. If developers don't align with those ideals, maybe open sourcing their work isn't for them.

"Open source" is abused too often these days as a marketing term, or something to fluff up your CV with, when it should be anything but that.

[2024throwaway]

It sounds like maybe the open source ecosystem isn't for you, actually.

You don't get to dictate how others work, sorry.

[2024throwaway]

I personally open sourced a project that started life as a paid product. The repository contained proprietary/customer information.

Are you suggesting I should have made this private information public? Or that I shouldn't have released the project at all?

[lolinder]

As they said, open source maintainers don't owe you any of those nice conveniences you're missing with a clean commit history. If someone is embarrassed at their commit history or worried that they committed secrets at some point they're free to start clean and open source that. Don't put up artificial barriers to people releasing their code.

This fact (nothing is owed you) is entirely independent from the squash-or-not debate.