I've been trying to push developers to use Arcanist and, furthermore, for arc land to be the accepted way to merge code (currently, we usually do git merge --no-ff). One of the concerns that people have with Arcanist is that it is perhaps a little too magical perhaps? --trace helps to see what is happening under-the-hood but can be very verbose. Perhaps a --dry-run mode would help?
I'm not sure we could define this consistently. For example, does arc land --dry-run mean arc land --hold, or arc land --keep --hold, or "don't touch the working copy at all, just pretend you're doing it"? I don't think it's possible to realistically implement the last case, since later steps depend on the results of earlier steps.
For arc diff, arc which or arc diff --only are both sort of dry runs.
I can't think of other commands where this would make too much sense offhand.
Hmm yeah, point taken.
Perhaps a better approach would be to add a verbosity level that is weaker than --trace (--info?) which would print a higher level description of what is happening (like "Calling 'diffusion.looksoon'").
Maybe we could add a type of message to the service call log that's purely human-readable, and with --trace it could render with a special color or be otherwise called out in a clear way -- basically, just make it easier to figure out what --trace means, without having to add a distinct --trace-lite. Then you could get --trace-lite with arc diff --trace | grep FOR-PUNY-HUMANS or something, if you really want (or we could let you exclude all the non-human-readable --trace output).
Yeah that sounds reasonable. Maybe we could also update the help text for the commands to include this stuff (although it could be too complex to easily represent... I'm not sure). Basically, detect the VCS and say "This command will do X, Y, Z"
I think for both arc diff and arc land, it's too complex to put in help text. arc which is basically that contextual help text for arc diff. I don't think it would be too unreasonable to add some equivalent for arc land, although it hasn't caused too many issues.
I think the revised version of arc land is about as good as we're likely to get. The new documentation is more clear, and the land operation no longer touches any local branches until the last second (or ever, with --hold), behavior is generally better, we restore the starting state if we fail, and the new output is more clear about what arc land is doing.
Given discussion in, e.g., T9973, I suspect we wouldn't help users much by printing commands, given that they all look like git push -- origin 3f238fh:master and similar and aren't really understandable without a sophisticated understanding of git.