8 ms·

Right. Imagine you are a terraform provider developer that is working on making sure their code is working with `opentf`. Lets imagine opentf does an initial

Right. Imagine you are a terraform provider developer that is working on making sure their code is working with `opentf`. Lets imagine opentf does an initial `v1.0.0` release of their code and your provider doesn't work. But you know it worked with the last FOSS release of `terraform`. What do you do? You find the common ancestor between these two projects, lets say 8a085b427b74ce3829500a59508b77465f1bbef0 (as that is the last commit `opentf` has from `terraform`). You will now run `git bisect` on the history between `8a085b427b74ce3829500a59508b77465f1bbef0` and `v1.0.0`. You will do a binary search on the 100-200 commits here, and everytime the source fails to build, or the test suite doesn't pass for whatever reason, you are making it much harder for the downstream provider to figure out why their code doesn't work. You can easily just try do this today and see what happens. Does the current untidy git history cause you any problems?

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 ago
  Bisecting 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 ago
    Bisecting 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 ago
      No, 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 ago
      You 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.

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 ago
Bisecting 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 ago
  Bisecting 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 ago
    No, 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 ago
    You 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.