Hi Nick, Nick Dokos <nicholas.do...@hp.com> writes:
> Agreed, but the point is that each and every variable renaming will need > to be checked in the light of these criteria. Bugs like this have the > potential of creating havoc for a long time to come. > > It may be easier to start from a working state than to try to fix the > current broken state piecemeal. The thing is... Org is working fine here. Of course, I'm not a "thousand eyes" by myself and some features might be broken in the current state, I will continue trying to catch them. > Besides, I'd rather have a single commit > in the history that does the right thing: having one commit that creates > the initial buggy state and then N commits at various times to fix the > brokenness might create all sorts of problems (breaking bisectability > e.g.) Theoretically agreed. But again: if you look at the diffs from the list of commits you sent, most of them are okay. Let's try to fix the ones that are *not* okay instead of going backward? I will revert the commits if things are really broken. Best, -- Bastien
