3 ms·

Interesting. I can definitely see a use case for this not when the PR is too large, but when you did something that the rest of the team needs quickly (i.e. I'm

by jujodi 7y ago

Interesting. I can definitely see a use case for this not when the PR is too large, but when you did something that the rest of the team needs quickly (i.e. I'm suggesting marketing it differently). For example, we've had a situation where we're in standup and someone says "has anyone seen this issue?" and another developer is like "oh yea I fixed that in my branch, I'll split it out so it can be merged separately". That's where your tool comes in. The "PR is too large" angle is a developer practice problem that you shouldn't try to solve with a bandaid, especially considering the larger the PR the more complex splitting it will be even with a tool to help.

clintoon 7y ago
Hey, thanks for the feedback. You make a great point. It should be less about splitting large pull requests but rather allowing for the ability to easily make your pull requests more atomic so that changes can be merged quicker when needed. A lot of times unnecessarily large pull requests are preventable, and prevention of the problem is more ideal than having a solution to it. (I do think there are some situations where it may be unavoidable in having a large PR such as doing something experimental but this tool isn't exactly fit for it yet) Will revise the copy