git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] git-cvsserver: handle CVS 'noop' command.

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 29, 2009, 22:45 UTC
Message-ID
<7v7i4denpg.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<1233264914-7798-1-git-send-email-stefan.karpinski@gmail.com>
Stefan Karpinski <stefan.karpinski@gmail.com> writes:
Show 31 quoted lines
> 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,
Previous: Stefan KarpinskiNext: Stefan Karpinski
Message 8 of 12 in “Re: [PATCH] git-cvsserver: run post-update hook *after* update.”
  1. Stefan KarpinskiJan 23, 2009
  2. Junio C HamanoJan 23, 2009
  3. git-cvsserver: run post-update hook *after* update.Stefan Karpinski, Jan 29, 2009
  4. Junio C HamanoJan 29, 2009
  5. Stefan KarpinskiJan 29, 2009
  6. Andy ParkinsJan 29, 2009
  7. git-cvsserver: handle CVS 'noop' command.Stefan Karpinski, Jan 29, 2009
  8. Junio C HamanoJan 29, 2009
  9. Stefan KarpinskiJan 29, 2009
  10. Junio C HamanoJan 29, 2009
  11. git-cvsserver: handle CVS 'noop' command.Stefan Karpinski, Jan 30, 2009
  12. Martin LanghoffJan 30, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.