Closed AkshayGoradia closed 7 years ago
@pkoenig10 Do you know why these Travis CI builds failed? Not sure why it didn't find a schema.rb file.
It looks like you've (I'm assuming accidentally) removed that file in this PR.
@AkshayGoradia the schema file you added back isn't the same as the one removed. Can you just modify the commit in which it was removed to revert any changes to this file?
Woops, added the schema file back – thank you!
@pkoenig10 looks like I'm failing the push build because it can't find the factory: organization_status. I thought I was supposed to delete it because Bruce created and merged in his own organization_status factory a while back (Travis CI already gave us an error before when it said the factory organization_status already existed). Thanks so much for your help!
It looks like your branch branched from your team branch before his organization status commits were commited. You should rebase your branch on top of the team branch before you commit. Just a friendly reminder to coordinate when multiple people are working on the same thing to make sure we don't break things as a result of merging.
I'm going to disable merging PRs for the whole repo, instead only allowing squash and merge. This makes our commit history cleaner and prevents (all too frequent) errors that result from merging.
I don't think that merge commits in master cause that many issues and would rather have the history if that's cool? I'm cool not allowing rebase & merge as I think that can cause weirdness (and makes it harder to revert), but in general I like having the full commit history
The main motivation is that usually PRs are filled with a bunch of small fix commits which, IMO, make the history harder to parse. This PR is an excellent example. Not to mention all the merge commits.
Of course there are some PRs with multiple "important" commits, but I would argue that if those features are so important they deserve to be preserved in the history, they should be separate PRs.
But you're right, I suppose it depends on the situation. For features and bugfixes being contributed to the team branch, we should use squash and merge. But when merging into master we definitely don't want to squash to keep the teams work history.
Added dependency tests for participant model, coverage for other models and cart bug fix in which items were being duplicated.