4 ms·
Perhaps the poster meant that the contents of the commits themselves make bisection slower? By touching a lot of files unnecessarily, incremental build systems
by sgtnoodle 4y ago
Perhaps the poster meant that the contents of the commits themselves make bisection slower? By touching a lot of files unnecessarily, incremental build systems have to do more work than otherwise.
- bombolo 4y agoBoth… and version jumps in formatting tool basically will touch every single file.
- makapuf 4y agoEvery file that changed because rules changed, which shouldn't be frequent, I don't remember black changed radically since its creation, do you have an example of some widespread syntax change ?
- bombolo 4y agoJust take a codebase and run black from different ubuntu releases. The funny thing is that if you run the versions backwards you will NOT obtain identical files with what you started with.
- eesmith 4y agoCould be? I've not heard of that problem, but I don't know everything. I'm not used to Python code (which is all that black touches) as being notably slow to build, nor am I used to incremental build systems for Python byte compilation. And I expect in a project with 2 developers which is big enough for things to be slow, then most of the files will be unchanged semantically speaking, only swapping back and forth between two syntactically re-blackened representations, so wouldn't an caching build system be able to cache both forms? (NB: I said "caching build system" because an incremental build system which expects time linear order, wouldn't be that helpful in bisection, which jumps back-and-forth through the commits.)