4 ms·

So you want reviewers to drop what they’re doing and take the time to pull in your changes to fix the typo, break up commit history by adding their change, inst

So you want reviewers to drop what they’re doing and take the time to pull in your changes to fix the typo, break up commit history by adding their change, instead of you fixing the mistake when it’s found, especially if it’s newly introduced? That’s pretty inconsiderate/lazy. Don’t be that teammate please.

dmoy 9y ago
Where I work the reviewer can seamlessly make a (suggested) edit to the change request which the author can accept with a single button click. So I guess it depends on the toolchain you have available, might be that GP has better tools than what you're used to. (To be clear, on submit the edit you make would appear as though author had did it themselves, so it doesn't polluted commit log at all)
- watwut 9y ago
  What tool do you use? That feature sounds cool.
  - dmoy 9y ago
    It is an internal only tool, idk of a public equivalent. Indeed a cool feature.
mrgriffin 9y ago
Similar to dmoy our code review workflow supports making a (small) change while reviewing. We use GitHub PRs, and the edit function combined with choosing a commit message like "!fixup <original commit message>" and `git rebase --autosquash` (or `git merge --squash` when merging the PR) works well. It's funny that you mention not wanting people to drop what they're doing as IMO that's one of the advantages of the approach I'm describing. The reviewer is already in the code, whereas the person being reviewed has often moved on to something else.