Re: [PATCH v2] remote show: fix the -n option

Johannes Schindelin [off-list ref] writes:

On Mon, 9 Jun 2008, Olivier Marin wrote:

quoted

diff --git a/builtin-remote.c b/builtin-remote.c
index c49f00f..efe74c7 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c

@@ -421,10 +421,10 @@ static void show_list(const char *title, struct path_list *list)
 
 static int show_or_prune(int argc, const char **argv, int prune)
 {
-	int dry_run = 0, result = 0;
+	int no_query = 0, result = 0;

Just for the record (not that I think anybody will care): I do not like 
this change.

I do not think nobody cares ;-).

At least I care enough to point out that I think you are wrong in this
case.  "show -n" in the scripted version was never about "dry-run" but
was about "no-query".

The problem with the area of the code this patch touches is that compared
to the scripted version, show and prune now share their codepaths a bit
more, and it is less easy to keep -n disabled for prune (I think it is a
nonsense because you cannot "prune" sensibly without looking at what the
remote has.  It was a bug in the scripted version and losing it in C
rewrite was a "silent bugfix") while resurrecting -n for show (which is a
quick way to view where the URL points at without bothering to see what
remote branches there are).

I think a sensible thing to do would be to:

 - Agree that "-n" in the sense that "do not query" and "--dry-run" in the
   sense that "do not do anything but report what you would do" are
   different options.

 - Resurrect "show -n" as a quick way to view URLs without bothering to
   contact the remote end that is needed to show "the tracked branches"
   information.

 - Forbid "prune -n", which is nonsense.

 - Make "prune --dry-run" truly useful --- contact the other end, and
   report what will be pruned without really pruning them.

 - Perhaps as an enhancement, "show -n" could show what tracking branches
   we have from the remote, even though the information may be stale.
   The scripted version did not do this, I think, and it would be an
   improvement.

I am CC'ing Shawn who authored 859607d (Teach 'git remote' how to cleanup
stale tracking branches., 2007-02-02) to give him a chance to point out
why I am wrong in saying "prune -n" is nonsense.  Maybe there is a valid
use case for that option, even though I do not see one.