Johannes Schindelin a écrit : > > No, I think that the information about stale branches and if the branches > are up-to-date is missing. In that sense, it is not like "route -n" at > all, which just skips one convenience step, but really a dry run, because > the result is different (as opposed to differently displayed). Am I wrong if I say that dry run is for commands that modify something? For example there is no "diff --dry-run" probably because diff does not change anything. A dry run has no real meaning for diff. This the same for "git remote show": it's a read-only command, it just display a summary of the remote and does not modify anything. With -n, it just skips the ls-remote (read-only) step and yes the result can be different, some parts can be missing. Exactly like "route -n", we skip the dns resolution, the host names are missing. Now, if we talk about "prune", I completely agree. A --dry-run flag make sens. But it's not the same thing than the "show -n" one. For what reason would I want to ask "prune" to skip the ls-remote step? What I would find more useful is to make "prune" show what it is doing (like "update") and add a --dry-run option to say "just show me, but do not touch anything". And we can even add a -p flag to "update" to say "prune at the same time". > It is a too long line (way over 80 characters). So yes, you should wrap > after the NULL here. Will fix. (my tabs were only 4 spaces long) >> In fact, it seems that get_ref_states() always return 0 or just die when >> an error occur. And that transport_get_remote_refs() never return if >> something goes wrong. >> >> So, what about removing got_states and use !no_query instead ? > > Hrmpf. I did not mean to die() there... I don't understand. Is it ok or not? Thanks for your comments, Olivier. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
