4 ms·

> I just want a single command that will do all the reverts cleanly Well, "rebase -i" will do that if it can be done but that’s unlikely unless your commits ha

> I just want a single command that will do all the reverts cleanly Well, "rebase -i" will do that if it can be done but that’s unlikely unless your commits have nothing in common. As changes will be necessary to adapt the code to the removal, it’s kind of hard to tell from the start what will be affected. Things might have knock on effects. It’s funny because I don’t really like Git but this is one of the case where what it does seem to be the best doable considering the actual complexity of the issue. If you just want to see what will be reverted you can do a three way diff between HEAD, the commit to revert and the commit you intend to revert to btw.

jrmg 4y ago
I think you’re maybe not getting what I want - unless I’m misunderstanding, the three way diff you suggest won’t work for this. In the simplest possible configuration that exhibits the pattern, there are commits like this … - A - B - C. To revert A cleanly, C must first be reverted because it changes code also changed in A. B touches a different part of the code and so doesn’t need to be reverted. Factor in a few days worth of commits from a large team, and it’s easy to see how very complex trees (even graphs, I think, so long as all the dependencies point backwards) can appear. But it _is_ always possible to get a minimal ordered chain of clean reverts that are required to revert A and all its dependencies. It’s definitely true that, as you say, things might have knock-on effects - like, perhaps there no textual dependency from B to A, but the logic is very much dependent. Thorough testing of the results is needed. But in a large well-factored project the chances of things being fine when an entire dependency chain is reverted are (in my experience doing things like this) surprisingly high.
- WastingMyTime89 4y ago
  > I think you’re maybe not getting what I want - unless I’m misunderstanding, the three way diff you suggest won’t work for this. To revert A you want to compare the difference between C and Z (commit before A) to the difference between A and Z so as to see where things which were changed in A will impact what’s in C while reverting so you can see what’s salvageable and what’s not. To come back to your chain of commits, use "rebase -i", do not pick A, and "rebase —skip" every following conflicts and you will end up in the state you want.

jrmg 4y ago

I think you’re maybe not getting what I want - unless I’m misunderstanding, the three way diff you suggest won’t work for this. In the simplest possible configuration that exhibits the pattern, there are commits like this … - A - B - C. To revert A cleanly, C must first be reverted because it changes code also changed in A. B touches a different part of the code and so doesn’t need to be reverted. Factor in a few days worth of commits from a large team, and it’s easy to see how very complex trees (even graphs, I think, so long as all the dependencies point backwards) can appear. But it _is_ always possible to get a minimal ordered chain of clean reverts that are required to revert A and all its dependencies. It’s definitely true that, as you say, things might have knock-on effects - like, perhaps there no textual dependency from B to A, but the logic is very much dependent. Thorough testing of the results is needed. But in a large well-factored project the chances of things being fine when an entire dependency chain is reverted are (in my experience doing things like this) surprisingly high.

WastingMyTime89 4y ago
> I think you’re maybe not getting what I want - unless I’m misunderstanding, the three way diff you suggest won’t work for this. To revert A you want to compare the difference between C and Z (commit before A) to the difference between A and Z so as to see where things which were changed in A will impact what’s in C while reverting so you can see what’s salvageable and what’s not. To come back to your chain of commits, use "rebase -i", do not pick A, and "rebase —skip" every following conflicts and you will end up in the state you want.