5 ms·

Is it common for open source projects to start clean with a single commit containing all the code instead of keeping the history? If author/OP are around, what

Is it common for open source projects to start clean with a single commit containing all the code instead of keeping the history? If author/OP are around, what is the reason for this? I can imagine one trying to hide iterations of shitty code or even copies of third parties which is reasonable I guess ( and I personally wouldn't care as a user/contributor to the project)

WhatsName 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      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. :)
      - lolinder 2y ago
        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.
      - LeafItAlone 2y ago
        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.
siumauricio 2y ago
Hey! Initially the project is not going to be open, since i included some payment integration and credentials and more stuff, but at the end i removed, so that's why i pushed in to a new repo to prevent to leak this information
- deleted 2y ago
  [deleted]

WhatsName 2y ago

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 2y ago
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 2y ago
  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 2y ago
    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. :)
    - lolinder 2y ago
      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.
    - LeafItAlone 2y ago
      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.

siumauricio 2y ago

Hey! Initially the project is not going to be open, since i included some payment integration and credentials and more stuff, but at the end i removed, so that's why i pushed in to a new repo to prevent to leak this information

deleted 2y ago
[deleted]