Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> On Mon, 9 Jun 2008, Olivier Marin wrote:
>
>> 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.
--
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
