All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Karpinski <stefan.karpinski@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] git-cvsserver: handle CVS 'noop' command.
Date: Thu, 29 Jan 2009 14:45:15 -0800	[thread overview]
Message-ID: <7v7i4denpg.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <1233264914-7798-1-git-send-email-stefan.karpinski@gmail.com> (Stefan Karpinski's message of "Thu, 29 Jan 2009 13:35:14 -0800")

Stefan Karpinski <stefan.karpinski@gmail.com> writes:

> The implementation is trivial: ignore the 'noop' command
> if it is sent. This command is issued by some CVS clients,
> notably TortoiseCVS. Without this patch, TortoiseCVS will
> choke when git-cvsserver complains about the unsupported
> command.
>
> Signed-off-by: Stefan Karpinski <stefan.karpinski@gmail.com>
> ---
>
> Since this change has no negative impact, is too simple to
> be wrong, and improves interaction with some clients, it
> seem to me like a no-brainer to apply it.
>
>  git-cvsserver.perl |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
> index fef7faf..c1e09ea 100755
> --- a/git-cvsserver.perl
> +++ b/git-cvsserver.perl
> @@ -188,7 +188,7 @@ while (<STDIN>)
>          # use the $methods hash to call the appropriate sub for this command
>          #$log->info("Method : $1");
>          &{$methods->{$1}}($1,$2);
> -    } else {
> +    } elsif ($1 ne 'noop') {
>          # log fatal because we don't understand this function. If this happens
>          # we're fairly screwed because we don't know if the client is expecting
>          # a response. If it is, the client will hang, we'll hang, and the whole
> -- 
> 1.6.0.3.3.g08dd8

Not a no-brainer at all, sorry.

Imagine what you would do when you discover another request a random other
client sends that you would want to ignore just like you did for 'noop'.
Viewed in this light, your patch is a very short sighted one that has a
big negative impact on maintainability.

A true no-brainer that has no negative impact would have been something
like the attached patch, that adds a method that does not do anything.

Even then, between req_CATCHALL and req_EMPTY, I am not sure which one is
expected by the clients, without consulting to the protocol documentation
for cvs server/client communication.  In the attached patch, I am guessing
from your patch that at least Tortoise does not expect any response to
it.

 git-cvsserver.perl |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git i/git-cvsserver.perl w/git-cvsserver.perl
index fef7faf..ca47e08 100755
--- i/git-cvsserver.perl
+++ w/git-cvsserver.perl
@@ -71,6 +71,7 @@ my $methods = {
     'log'             => \&req_log,
     'rlog'            => \&req_log,
     'tag'             => \&req_CATCHALL,
+    'noop'            => \&req_CATCHALL,
     'status'          => \&req_status,
     'admin'           => \&req_CATCHALL,
     'history'         => \&req_CATCHALL,

  reply	other threads:[~2009-01-29 22:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1232144521-21947-1-git-send-email-stefan.karpinski@gmail.com>
     [not found] ` <1232144521-21947-2-git-send-email-stefan.karpinski@gmail.com>
2009-01-23  5:43   ` [PATCH] git-cvsserver: run post-update hook *after* update Stefan Karpinski
2009-01-23  8:00     ` Junio C Hamano
2009-01-29 21:58       ` Stefan Karpinski
2009-01-29 22:48         ` Junio C Hamano
2009-01-29 23:26           ` Stefan Karpinski
2009-01-29 22:56         ` Andy Parkins
2009-01-29 21:35 ` [PATCH] git-cvsserver: handle CVS 'noop' command Stefan Karpinski
2009-01-29 22:45   ` Junio C Hamano [this message]
2009-01-29 23:39     ` Stefan Karpinski
2009-01-29 23:46       ` Junio C Hamano
2009-01-30  1:12         ` Stefan Karpinski
2009-01-30  1:32     ` Martin Langhoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v7i4denpg.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=stefan.karpinski@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.