3 ms·
My bias here is that I don't tend to use commits the same way you do. I would look through each PR that had been merged between now and then. Specifically looki
by starttoaster 3y ago
My bias here is that I don't tend to use commits the same way you do. I would look through each PR that had been merged between now and then. Specifically looking for PRs that look like they might change the thing that I'm having issues with. Untidy git histories are so common that it's not really worth counting on, to me. A PR is a body of work that I find actually seems to matter. I wouldn't reach the same hangup you had. On the flipside, when people overload their PRs with 3-4+ deliverable items, that tends to irk me.
- Foxboron 3y agoBisecting to find the root cause is always going to be a better strategy if you know there is a good version. I really recommend adopting this strategy.
- starttoaster 3y agoBisecting can be a good strategy. But you need to look through 100 commits. I need to look through 5-8 PR diffs. Everyone thinks they have the best strategy because they get results with it. Anyway, I'll try your strategy if mine is failing.
- Foxboron 3y agoNo, it does a binary search over the 100 commits. You would probably hit the issue before you hit 7 or 10 commits depending on how lucky you are.
- lijok 3y agoYou should play around with git bisect - seems like you've not used it much. It's a life changer when it comes to finding what broke. Don't forget, a project like Terraform is too big. No one person can know how the whole system works. Trying to look through PRs as a means of debugging is a fools errand. You have to take on a different mindset when working on these large codebases.