The point is that others see that it's there, they can start to take it into account when they develop their solutions. Of course if there are problems with pe

The point is that others see that it's there, they can start to take it into account when they develop their solutions. Of course if there are problems with people depending on not yet final code that seems more of a higher level communication issue than git workflow issue. Again, if atomic unit of functionality needs huge towers of stacked PRs that indicates that they are not really atomic and the design phase (communication) seems to be missing. After all the reviewer should know about the design, the HTTP handler + adapter should not be a mystery to the reviewer. And so on... ... Now, that said, sometimes looking at a big PR as whole takes up less review time than in daily/weekly increments. But if the reviewer only sees the thing late in the dev process plus the design is not agreed upon then that means the developer writes a lot of code that might go straight to /dev/null when the reviewer disagrees with the fundamental design of it. The assumptions needed for these huge dangling WIP PRs to make sense seem very strange (risky and suboptimal) :o