Skip to content

Commit a68fbfc

Browse files
authored
Merge pull request #1223 from moodle/timhunt-patch-1
Fix typos in fixups.md
2 parents 3b82df0 + 29778e0 commit a68fbfc

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

general/development/abc/fixups.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -139,10 +139,10 @@ If you would like to see an example of this being done in a really large change,
139139

140140
## Summary
141141

142-
When replying to a reviewer, you can make their task easier by pushing a branch where it is easy to see what changes you made. However, for integration, we want a clean branch that is ready to be merged. It is possible to have both by pushing your changes with two different branch names/ Using a few simple git commands it is not too much trouble to make both branches.
142+
When replying to a reviewer, you can make their task easier by pushing a branch where it is easy to see what changes you made. However, for integration, we want a clean branch that is ready to be merged. It is possible to have both by pushing your changes with two different branch names. Using a few simple git commands it is not too much trouble to make both branches.
143143

144144
Even though it is not that much work do to this, it is not always worth doing this. Some cases where I would not bother to do this:
145145

146146
1. If the whole changes is small and simple, for example a one-line fix with one added unit test to verify it, then it is no trouble for someone to review the whole thing.
147-
2. If the requested change was really minor, for example if the review suggested you edit one comment to make it a bit clearer and you have doe that, then this is another case where just pushing the amended branch is probably fine.
147+
2. If the requested change was really minor, for example if the review suggested you edit one comment to make it a bit clearer and you have done that, then this is another case where just pushing the amended branch is probably fine.
148148
3. The other time when there is no point doing this is at the other extreme. Suppose the result of the first review was to suggest a completely different approach to the code, so you have largely re-written the change. In that case, the difference between the first and second attempted implementation is unlikely to be of any value. Just concentrate on making your second version of the code as good as possible and push that.

0 commit comments

Comments
 (0)