4 ms·
Why are you allowing such large pulls? Everyone who complains about githubs pull request UI always has the same root cause, huge, long lived reviews. Don't fi
by joneholland 10y ago
Why are you allowing such large pulls?
Everyone who complains about githubs pull request UI always has the same root cause, huge, long lived reviews.
Don't fix bad process with more process and tooling. Fix it at the root.
- wildfire 10y agoBecause the feature is large? Or the developer acted normally and split thing into multiple, small, independant commits? If the submittor then takes a lot of time between comments and performing changes, is the commentor to blame for a PR being long-lived? Don't assume everything is bad process.
- joneholland 10y agoWhy can't it be a series of small PRs then? Or do you not do continuous delivery?
- acidbaseextract 10y agoBecause then the reviews for the connected PRs ends up being hideous to track. Either you can: • Submit the PRs one at a time... which is awful. Why not work on them in parallel? • Submit your series of PRs all at once, then you have to set the PR base of each one to the following one to make the github diff view actually reasonable for reviews. THEN, when you have a code change based on feedback on the first PR, you have to merge it into all the later dependent PRs. THEN, you have to have to jiggle the PR bases very carefully when you're landing the PRs, otherwise it will merge them all into each other, and you end up with one ginormous commit landing—defeating the point of the small commits. AND unless you're using a squash based workflow, you'll end up with that giant merge mess in the middle of your commit history.