Hacker News new | past | comments | ask | show | jobs | submit login

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.



Could 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.)


Both… and version jumps in formatting tool basically will touch every single file.


Every 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 ?


Just 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: