Should fetchIt rollback to a last know good commit when it encounters an Apply error?
Should fetchIt track back commits and refuse to checkout a bad commit?
In previous discussions we thought yes to both and there is a PR in the works for this ^^ however I think we should not track bad commits at this time, because it is impossible for FetchIt to know what a bad commit is.
I think rollback is useful, but tracking bad commits might be out of scope. Here's why:
If rollback & TrackBadCommits is enabled - but the fix is outside the git code - like, a directory is supposed to exist on the host that doesn't - that would result in a workflow that can never progress to a good state because it's not the commit that's broken, it's the host. So, I think this means we can never confidently enable TrackBadCommits - there is no way for fetchit to know if the issue is the code in the commit or something else on the host.
btw, I'll point out that it was my (bad?) idea to track bad commits in the first place :)
Applyerror?In previous discussions we thought yes to both and there is a PR in the works for this ^^ however I think we should not track bad commits at this time, because it is impossible for FetchIt to know what a bad commit is.
I think rollback is useful, but tracking bad commits might be out of scope. Here's why: If rollback & TrackBadCommits is enabled - but the fix is outside the git code - like, a directory is supposed to exist on the host that doesn't - that would result in a workflow that can never progress to a good state because it's not the commit that's broken, it's the host. So, I think this means we can never confidently enable TrackBadCommits - there is no way for fetchit to know if the issue is the code in the commit or something else on the host.
btw, I'll point out that it was my (bad?) idea to track bad commits in the first place :)