4 ms·

> It's insane that everyone is re-writing their development history to avoid issues with their source control system people rewrite their history because theyr

> It's insane that everyone is re-writing their development history to avoid issues with their source control system people rewrite their history because theyre irresponsible with pushes. it's got nothing to do with the source control system. You're supposed to push small isolated encapsulated commits with a good names. I never do that while developing. I would have the same problem on any VCS > And squashing should never be preferred by anyone if the tooling was actually any good. For PRs? You should be able to define a group of commits and look at it as a whole, not just operate on a single commit. For clutter? once again responsible commits are supposed to be small, isolated, single change commits. so in a large feature a good developer would have tons of commits this makes the PR easier to understand and review... and when the features finally merged, you don't necessarily need those commits you just need the feature. I think your issue might just be with understanding how version control is supposed to work.

feoren 3y ago
> I think your issue might just be with understanding how version control is supposed to work. This has nothing to do with how it's "supposed to" work, and all to do with the standards and constraints we're putting on ourselves here. No god has made any commandments about how thou shalt organize your commits. > I would have the same problem on any VCS ... commits are supposed to be small, isolated, single change commits It sounds to me like you've got some self-imposed issues. Nobody told you every commit has to be a "single change", unless you're very loose with what you mean by that. Sure, a commit should be a group of related functionality, such that you either want all of it or none of it. But it's perfectly fine for one commit to involve 20+ files. In fact one of the (many) things people hated about CVS was that you couldn't bundle changes like this! And if you're that concerned about commits being single changes, then you should never squash! It's hypocritical to say every commit should be tiny, but then squash them! > this makes the PR easier to understand and review I already addressed this. The problem is the 1:1 mapping between commits and PRs. There's no reason for that.
nonethewiser 3y ago
> people rewrite their history because theyre irresponsible with pushes. it's got nothing to do with the source control system. You're supposed to push small isolated encapsulated commits with a good names. I never do that while developing. Its a good ideal but not realistic.
- nirvdrum 3y ago
  Why isn’t it realistic? I’m not trying to be glib. With “git add -p” and “git checkout -p” I find it fairly straightforward to do. I think usage of “git commit -a” or “git commit .” is the source of a lot of messy commits, but is often easily avoidable. Good commit hygiene is just as important as good tests, good method names, etc.
mschuster91 3y ago
> people rewrite their history because theyre irresponsible with pushes. it's got nothing to do with the source control system. Corporate policy often is to push at the end of the day, so in the event you spill some coffee over your laptop, all you'll lose is a day of lost work and a day to set up a new laptop.

feoren 3y ago

> I think your issue might just be with understanding how version control is supposed to work. This has nothing to do with how it's "supposed to" work, and all to do with the standards and constraints we're putting on ourselves here. No god has made any commandments about how thou shalt organize your commits. > I would have the same problem on any VCS ... commits are supposed to be small, isolated, single change commits It sounds to me like you've got some self-imposed issues. Nobody told you every commit has to be a "single change", unless you're very loose with what you mean by that. Sure, a commit should be a group of related functionality, such that you either want all of it or none of it. But it's perfectly fine for one commit to involve 20+ files. In fact one of the (many) things people hated about CVS was that you couldn't bundle changes like this! And if you're that concerned about commits being single changes, then you should never squash! It's hypocritical to say every commit should be tiny, but then squash them! > this makes the PR easier to understand and review I already addressed this. The problem is the 1:1 mapping between commits and PRs. There's no reason for that.

nonethewiser 3y ago

> people rewrite their history because theyre irresponsible with pushes. it's got nothing to do with the source control system. You're supposed to push small isolated encapsulated commits with a good names. I never do that while developing. Its a good ideal but not realistic.

nirvdrum 3y ago
Why isn’t it realistic? I’m not trying to be glib. With “git add -p” and “git checkout -p” I find it fairly straightforward to do. I think usage of “git commit -a” or “git commit .” is the source of a lot of messy commits, but is often easily avoidable. Good commit hygiene is just as important as good tests, good method names, etc.

mschuster91 3y ago

> people rewrite their history because theyre irresponsible with pushes. it's got nothing to do with the source control system. Corporate policy often is to push at the end of the day, so in the event you spill some coffee over your laptop, all you'll lose is a day of lost work and a day to set up a new laptop.