4 ms·

What does git or Perforce have to do with refactoring? Why would whatever version control you're using matter? > tools for mass renaming that try to guarantee

What does git or Perforce have to do with refactoring? Why would whatever version control you're using matter? > tools for mass renaming that try to guarantee that there are no regressions beyond sed or whatever a fancy IDE already does? What kind of voodoo magic are we talking about here? Did Google solve the halting problem and I just haven't noticed yet...

bri3d 5y ago
Disclaimer: I haven't worked at Google, but you can easily read their papers like https://dl.acm.org/doi/pdf/10.1145/2854146 https://dl.acm.org/doi/pdf/10.1145/2854146 and understand what's going on. Refactoring tooling is integrated with the revision control system because in a giant codebase with thousands of contributors, you need to split a refactoring patch into smaller chunks and ideally use semantic rather than text-based diff tooling, or the changes will never get reviewed or merged before they conflict with more changes. As for the actual renaming, yes, definitely beyond what sed does but probably around what the fanciest IDE does. Imagine a big global symbol dependency graph produced by the entire build toolchain all at once and cached, I think? Also, this isn't the halting problem unless your codebase allows for fully dynamic invocation :)
- worthless-trash 5y ago
  Aren't all function pointers dynamic invocation ? Or is "fully" one of those words that i'm not grasping in context.
  - DaiPlusPlus 5y ago
    > Aren't all function pointers dynamic invocation? Given that compilers can be smart-enough to detect "non-dynamic" function-pointer invocation (e.g. when an execution-trace proves that a function-pointer parameter always points to the same function address), it's not safe to say that "all" function pointer invocations are dynamic. Another case to consider is when one implements (Smalltalk-style) OOP with message-passing: in many cases it's possible to build that without needing to use function-pointers at all.
    - eru 5y ago
      Also you have a type system. And even in C function pointers have types. So you can exclude many things that would in-principle be possible.
      - worthless-trash 5y ago
        > C function pointers have types. I'm not 100% sure, but i remember that i could have have both a two and three function argument be called with the same function pointer, its probably UB however i think that as long as any dereferenced functions adhered to the standard argument behavior of the platform specific calling convention it worked, and i dont think gcc, clang or msvc complained, but my memory might be wrong.
tialaramex 5y ago
The rename has to be atomic, which is one of the things your revision control system gives you, unless it's like CVS or something worse†. So, that's a necessary part of the solution space. You want there to be two states: State A where the thing was called old_name and State B where the thing is called new_name. State AB where some code thinks it is called old_name but other code thinks it is called new_name is broken, and must not exist. † This might seem outrageous to modern programmers, but CVS thinks in terms of files, so from its point of view it's fine if out of sixty files you tried to commit, 48 of them succeeded and 12 failed. Good luck fixing the resulting mess.
- tonyarkles 5y ago
  I remember having to go backwards from SVN to CVS for a project a long time ago, and I was so shaken by the fact that CVS couldn’t do atomic commits with multiple files!
  - bonzini 5y ago
    Yeah, my favorite model of how git operates is "rewind all the way back to RCS, add atomic commits and take it from there". SVN, baz/bzr and friends are what you get if you add networking before atomic commits. Git is what you get if you start with the proper data model and only then add networking.
plantsbeans 5y ago
I believe the commenter is referring to system where you take a giant “git sed” and automate a rather complicated process: 1. break up one huge diff into a set of many (hundreds or thousands) patches, where each individual patch only touches files in a particular subsystem. 2. send all those patches to the appropriate system owners and run the appropriate tests. 3. manage the actual merging of successful patches, as well as communicating to the original author any individual patches that might need more attention e.g. based on patch review feedback. as you might imagine, it’s probably a pretty involved process to touch thousands of lines of code in a complicated system.
patmorgan23 5y ago
There are multiple branches being actively worked on. It would be very easy for someone to murge in an unrefacatored branch and now half the code base is using the old call.
- eru 5y ago
  You'd want something like https://bors.tech/ https://bors.tech/ to avoid that. Bors works for git. Google has similar tooling for their system. (I think it's called the 'train'.)

bri3d 5y ago

Disclaimer: I haven't worked at Google, but you can easily read their papers like https://dl.acm.org/doi/pdf/10.1145/2854146 https://dl.acm.org/doi/pdf/10.1145/2854146 and understand what's going on. Refactoring tooling is integrated with the revision control system because in a giant codebase with thousands of contributors, you need to split a refactoring patch into smaller chunks and ideally use semantic rather than text-based diff tooling, or the changes will never get reviewed or merged before they conflict with more changes. As for the actual renaming, yes, definitely beyond what sed does but probably around what the fanciest IDE does. Imagine a big global symbol dependency graph produced by the entire build toolchain all at once and cached, I think? Also, this isn't the halting problem unless your codebase allows for fully dynamic invocation :)

worthless-trash 5y ago
Aren't all function pointers dynamic invocation ? Or is "fully" one of those words that i'm not grasping in context.
- DaiPlusPlus 5y ago
  > Aren't all function pointers dynamic invocation? Given that compilers can be smart-enough to detect "non-dynamic" function-pointer invocation (e.g. when an execution-trace proves that a function-pointer parameter always points to the same function address), it's not safe to say that "all" function pointer invocations are dynamic. Another case to consider is when one implements (Smalltalk-style) OOP with message-passing: in many cases it's possible to build that without needing to use function-pointers at all.
  - eru 5y ago
    Also you have a type system. And even in C function pointers have types. So you can exclude many things that would in-principle be possible.
    - worthless-trash 5y ago
      > C function pointers have types. I'm not 100% sure, but i remember that i could have have both a two and three function argument be called with the same function pointer, its probably UB however i think that as long as any dereferenced functions adhered to the standard argument behavior of the platform specific calling convention it worked, and i dont think gcc, clang or msvc complained, but my memory might be wrong.

tialaramex 5y ago

The rename has to be atomic, which is one of the things your revision control system gives you, unless it's like CVS or something worse†. So, that's a necessary part of the solution space. You want there to be two states: State A where the thing was called old_name and State B where the thing is called new_name. State AB where some code thinks it is called old_name but other code thinks it is called new_name is broken, and must not exist. † This might seem outrageous to modern programmers, but CVS thinks in terms of files, so from its point of view it's fine if out of sixty files you tried to commit, 48 of them succeeded and 12 failed. Good luck fixing the resulting mess.

tonyarkles 5y ago
I remember having to go backwards from SVN to CVS for a project a long time ago, and I was so shaken by the fact that CVS couldn’t do atomic commits with multiple files!
- bonzini 5y ago
  Yeah, my favorite model of how git operates is "rewind all the way back to RCS, add atomic commits and take it from there". SVN, baz/bzr and friends are what you get if you add networking before atomic commits. Git is what you get if you start with the proper data model and only then add networking.

plantsbeans 5y ago

I believe the commenter is referring to system where you take a giant “git sed” and automate a rather complicated process: 1. break up one huge diff into a set of many (hundreds or thousands) patches, where each individual patch only touches files in a particular subsystem. 2. send all those patches to the appropriate system owners and run the appropriate tests. 3. manage the actual merging of successful patches, as well as communicating to the original author any individual patches that might need more attention e.g. based on patch review feedback. as you might imagine, it’s probably a pretty involved process to touch thousands of lines of code in a complicated system.

patmorgan23 5y ago

There are multiple branches being actively worked on. It would be very easy for someone to murge in an unrefacatored branch and now half the code base is using the old call.

eru 5y ago
You'd want something like https://bors.tech/ https://bors.tech/ to avoid that. Bors works for git. Google has similar tooling for their system. (I think it's called the 'train'.)