On Mon, Apr 28, 2014 at 6:32 PM, Jim J. Jewett <jimjjew...@gmail.com> wrote: > (1) Should fixes to a docstring go in with a patch, even if they > aren't related to the changing functionality? > > [...] > > It is best if a commit changes one small thing at a time. > On the other hand, Nick recently posted that the minimal overhead of a > patch commit is about half an hour. >
It could be much less. As an example, http://bugs.python.org/issue19943 has been closed 9 minutes after the report, it didn't have a patch and the fix had to be applied/grafted/merged on 3 branches. The time passed between the first commit and the push is less than a minute too. Clearly the time increases if you have to run the test suite or if there is a merge conflict/push race, and further decreases if there is a simple typo-fix on default only and a patch already available. > Is that overhead enough to override the one-issue-per-patch guideline? > That said, if the main fix should go only on default and it has a smaller unrelated fix that should also go on default only, then doing it together is generally OK (for some value of "unrelated" -- the fix should still be small and near the code you touched for the main fix). If the unrelated fix needs to be ported on all the branches (or in general in branches where the main fix shouldn't go), it's better to have two separate patches. If you commit the smaller fix together with the bigger one, and then decide to backport it, you will have to do a null merge and it gets slightly more complicated. Best Regards, Ezio Melotti _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com