3 ms·

If someone has a clean commit that is a district unit of functionally and passes all tests, why would that not have simply been committed as an independent chan

If someone has a clean commit that is a district unit of functionally and passes all tests, why would that not have simply been committed as an independent change prior to continuing work? The only way a consistent unit of code would exist to revert is by stacking it on such a change. I am not sure I have ever encountered a situation where targeting a single commit to revert would have actually worked(from a rebased merge). I would go as far as saying that git revert should be a nuclear option reserved for only the worst of situations(urgent PE hotfix?). If something is worth reverting and was missed by the engineer and the reviewers, it seems the like fix should also atomically contain the explaination with a test to prove the issue was fixed. Because of this mentality, I believe it has been several years since I have seen a 'revert' in the wild. Maybe I am alone in the industry with my opinion. However, I have seen the same patterns unfold on many teams. ...A lot of concerns with switching to a dead simple git workflow that fade almost immediately after trying it. Just my experience (backend batch jobs, applications, and rest services).

jrmg 4y ago
If someone has a clean commit that is a district unit of functionally and passes all tests, why would that not have simply been committed as an independent change prior to continuing work? This is exactly the kind of change I’m talking about - the problem is it’s later discovered to have flaws that the tests did not reveal, but enough time has passed that later changes depend on it. I am not sure I have ever encountered a situation where targeting a single commit to revert would have actually worked(from a rebased merge). It almost always worked in my experience. The systems we’ve worked on must be architected differently. If something is worth reverting and was missed by the engineer and the reviewers, it seems the like fix should also atomically contain the explaination with a test to prove the issue was fixed. Agreed - the problem comes if the fix is not obvious and a fix cannot immediately be applied. In our workflow, when we have belatedly learned of a problem a change is causing, a revert should then be done to keep the integrity of the main branch. I should stress that this is an exceptional case - but we did see it a few times a year.

jrmg 4y ago

If someone has a clean commit that is a district unit of functionally and passes all tests, why would that not have simply been committed as an independent change prior to continuing work? This is exactly the kind of change I’m talking about - the problem is it’s later discovered to have flaws that the tests did not reveal, but enough time has passed that later changes depend on it. I am not sure I have ever encountered a situation where targeting a single commit to revert would have actually worked(from a rebased merge). It almost always worked in my experience. The systems we’ve worked on must be architected differently. If something is worth reverting and was missed by the engineer and the reviewers, it seems the like fix should also atomically contain the explaination with a test to prove the issue was fixed. Agreed - the problem comes if the fix is not obvious and a fix cannot immediately be applied. In our workflow, when we have belatedly learned of a problem a change is causing, a revert should then be done to keep the integrity of the main branch. I should stress that this is an exceptional case - but we did see it a few times a year.