4 ms·
If you use Pull Requests with squashed commits, you can do exactly the same process as described here by isolating the issue to a PR then restoring the branch a
by ZephyrBlu 6y ago
If you use Pull Requests with squashed commits, you can do exactly the same process as described here by isolating the issue to a PR then restoring the branch and bisecting from there.
It seems like a small price to pay for a clean history, given the rarity of occurrences like this.
- NateEag 6y agoIt seems like a needless price to pay, since the whole point of keeping history is to help analyze problems and past states. The author has only used bisect for a head-scratcher once, but I've used it often, sometimes to pin down bugs in code I'd never even looked at before. That's not feasible if the commits are huge.
- ZephyrBlu 6y agoYou do keep the history in the branch, it's just out of the way unless you really need it. Also, the method I described has nothing to do with commits. PRs and small commits aren't mutually exclusive.
- NateEag 6y agoYou have to go dig the branch out of the central repo, though, which is annoying and takes time. That was the price I was thinking of. You're certainly right that PRs and large commits are orthogonal.
- jeremyjh 6y agoI've done this maybe once or twice a year.
- ZephyrBlu 6y agoNavigate to PR -> Restore Branch -> `git checkout <branch>` How is this annoying or time consuming? It takes less effort than adding, committing and pushing changes.
- NateEag 6y agoBecause with a test suite, git bisect, and a history that's been reasonably well cared for, I can just tell git "find me the bug" and go do something else until it's done. I don't like having to go fiddle manually for that to work. Ideally you have CI set up so the average test failure email points you to the small patch that broke it. For bugs from the wild that doesn't work, obviously, but I still prefer less friction.
- mixmastamyk 6y agoSounds like you've moved the work forward, where it always has to be done. Rather than doing it in a lazy manner, where most instances can be avoided. Is that a good trade-off?
- NateEag 6y agoLike most tradeoffs, it depends on the particular circumstances, I think. I don't have this set up in my current gig, because we have more pressing priorities. It is incredibly useful when you do have it, though. Generally it's more important for really large projects - IIRC Android is really strict about not merging branches containing any commits that break tests, for exactly this reason. As that implies, you wind up rewriting branches in this approach, too, but for different reasons.
- apta 6y agoIs it always possible to restore branches from the PR? e.g. do some code review systems automatically delete committed branches after a certain time period?
- deleted 6y ago[deleted]
- jeremyjh 6y agoIt makes the initial bisect easier and faster as well, because every commit is a fully working one, and there are no trivial commits that still have to be rebuilt and bisected over. Plus all the commits are found in the order they were introduced to master, rather than randomly interleaved with other feature branches that were built at the same time. Personally I would think any kind of branch cleanup to get the history of a feature branch into a presentable state is a significant price to pay. I've only had to restore a PR branch a handful of times to find the particular culprit.
- yipbub 6y agoYeah, I'm happy I learned about `bisect` with this blog post, but I (almost) always make sure my squashed commits build. However, I try to only squash into logical units, I don't try to cram the whole PR into one commit
- mpawelski 6y agoYou mean Gihub? I'm not familiar with squashed commit there but it seems that it requires that original branch is not removed from remote? Because if there is no reference to this branch then it will be garbage collected after some time. You don't remove PR's branches after merging them?