On Wed, Apr 4, 2012 at 1:37 PM, Tom Bachmann <[email protected]> wrote: >> (Maybe I'm wrong and we should really be doing five-line pull requests >> as long as they are atomic. I'm not experienced enough with git to say >> for sure whether that's idiocy or actually the best approach. Maybe >> somebody should try this out.) >> > > The real problem with such extremely short pull requests is that it actually > takes some amount of time to review anything. So if you were to have so many > short pull requests, you would have to manage locally several different > (tiny) branches waiting for review, and bigger branches in which you > actually work. I haven't managed to do this very efficiently so far.
Yeah, this is where the merging instead of rebasing thing strategy comes in handy. You just do all your changes in branches, and merge them together when you need them. Since the merge doesn't affect the original commit, this won't create duplicate commits, and will extend naturally when the commit is merged into master. But ideally, we should strike a balance between too short pull requests and too long ones. And if we can get the reviews done quickly (a pipe dream I know), then it's really not an issue. Aaron Meurer -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
