patchgit-cvsimport.perl: Print "UNKNOWN LINE..." on stderr, not stdout.

Signed-off-by: Jim Meyering <meyering@redhat.com>
---
I'm used to filtering git-cvsimport's noisy stderr, but this
diagnostic appears on stdout.  Looks like an oversight.
Now that I'm using cvsps-2.2b1, I see tons of these.

 git-cvsimport.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

On Tue, Aug 05, 2008 at 04:54:42PM +0200, Jim Meyering wrote:

There are a ton of things that go to stdout:

  $ perl -ne '/print (\S+)/ && print "$1\n" git-cvsimport.perl |
    grep '^#' | wc -l
  18

though many are only activated via "-v". Maybe it is worth putting all of them to stderr? I really don't see why cvsimport should ever produce any output on stdout.

-Peff

On Tue, Aug 05, 2008 at 11:28:36AM -0400, Jeff King wrote:

Urgh, somehow I managed to get a typo into my cut and paste. It should be

  grep '^"'

(i.e., we are getting rid of "print STDERR" and "print $fh"; this is admittedly not very robust, but I just wanted an approximation of how many there were).

-Peff

Jeff King <peff@peff.net> wrote:

A quick scan (post-patch)

    $ grep 'print ' git-cvsimport.perl|grep -vE 'STDERR|opt_v'
    print $f "$_=$conv_author_name{$_} <$conv_author_email{$_}>\n";
    print $fh $line;
    print $fh $buf;
    print $cvspsfh $_;
    print $fh
    print "SKIPPING $fn v $rev\n";

suggests that if you don't count the "SKIPPING..." diagnostic you'd get for each "-S REGEXP"-skipped name, the "UNKNOWN LINE" diagnostic is the only one that goes to stdout but that is not protected by an $opt_v guard.