Eric Rescorla writes: > I don't believe I am asking for this, just auto-squash on submit. I > certainly understand if it's your position that you have higher priorities, > that's fine, but it's not fine to remove the ability to do squashed reviews > before something like that lands.
Perhaps the distinction between the processes here is that it is typical in Mozilla process to attach several logical changes to one bug report if they are all required to fix the single bug. Filing dozens of bugs can become unnecessary overhead if changesets are going to land together anyway, but there can be advantages to multiple bug reports, when backouts or uplifts are required, for example. I assume none of us want different logical changes in one changeset. This makes reviewing and regression tracking harder. [1] auto-squash on submit of course would not be fine for different logical changes on one bug report, without some mechanism to describe which changes are evolution-during-development, to be squashed, and which are separate logical changes, to remain separate. The current model relies on the submitter to make the distinction. Often it is helpful for reviewers to be able to see the final state, including all logical changes. Being able to do that is one of the benefits of push-to-review systems. I assume the intention was not to remove that view, but to remove implication of a single review request for all logically-independent changes. [1] https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/#many-small-commits _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform