I think us as committers should decide if the commits make sense to keep all of them or squash them into one. But bug fixes should usually be only one commit, and major refactors are not usually sent by non committers
El El mar, 7 ago 2018 a las 23:02, Chris Brody <chris.br...@gmail.com> escribió: > > > I would favor a place where a contributor can mark if s/he would > > > recommend the committer should *not* use the squash option. > > > > That of course could be defined in the contributor guidelines or PR > > template (although there it might be a bit confusing to new users that > > don't know what this is talking about). Do you know how other project > > handle that? > > Haven't seen anything like this before. > > > In the end it is always the decision of the committer how contributed > > code makes it into the code base, so having good guidelines for us > > would probably be the best solution, right? > > Yes. General common sense may prove to be the major principle, as I > think it has in the past. For example: > * Someone raises a PR with bug fixes and major refactoring in separate > commits (should not be squashed) > * Someone else raises a PR with a single fix, but with extra commits > to fix issues with the first commit (*should* be squashed) > > I wonder if we can track these discussions in a better way, somehow. I > have no time to help with these things right now. I think better > tracking could help ensure these important tasks do not get forgotten. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
