The question is why you would want to see it. In day-to-day use you can trust Gradle that it will execute exactly what was needed for what you asked for. If you say gradle test, Gradle will run everything necessary to execute your tests.
The only time that I can come up with where you really care about seeing what tasks get executed in detail is if you are debugging an issue or adding some new task and making sure it is in fact executed. For that case you can use either --scan or --profile or the new --console=verbose mode we’ll add in 4.3.
That’s not how I see it. It’s absolutely not clear when I run a task, which tasks will be attempted to run.
This is very basic information that I am very interested in.
Hiding the most basic information of a build (which tasks were considered for execution and which ones did run) does not improve understanding of a build.
I trust Gradle to know that but I don’t trust myself to know that without help.
To substantiate my argument a little bit more, here’s a very common example of how showing which tasks get to run can help.
I change a file in a source that I assume is included in sources, say src/main/resources/blah.txt. I expect the tests to run again, but for some reason, this directory is excluded from sources and the tests don’t even run.
If I saw that the test task didn’t even run, I wouldn’t assume my change had worked. This could cost a lot of time to fix later, specially for junior developers that do not have full understanding of a build (but even experienced people cannot understand all aspects of large builds).
You decided to hide this crucial information to save a few lines of output. Those few lines of output didn’t cost anything. They were useful. Hiding them does not improve anything at all.