From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Witten Subject: Re: [PATCH RFC 3/6] send-email: Handle "GIT:" rather than "GIT: " during --compose Date: Sat, 11 Apr 2009 15:45:53 -0500 Message-ID: References: <1239139522-24118-1-git-send-email-mfwitten@gmail.com> <1239139522-24118-2-git-send-email-mfwitten@gmail.com> <1239139522-24118-3-git-send-email-mfwitten@gmail.com> <7vprfjf11h.fsf@gitster.siamese.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: git@vger.kernel.org To: Junio C Hamano X-From: git-owner@vger.kernel.org Sat Apr 11 22:49:24 2009 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1Lsk6t-0001x3-1F for gcvg-git-2@gmane.org; Sat, 11 Apr 2009 22:47:31 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758785AbZDKUp7 convert rfc822-to-quoted-printable (ORCPT ); Sat, 11 Apr 2009 16:45:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757491AbZDKUp6 (ORCPT ); Sat, 11 Apr 2009 16:45:58 -0400 Received: from mail-qy0-f118.google.com ([209.85.221.118]:41124 "EHLO mail-qy0-f118.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756695AbZDKUp5 convert rfc822-to-8bit (ORCPT ); Sat, 11 Apr 2009 16:45:57 -0400 Received: by qyk16 with SMTP id 16so2988681qyk.33 for ; Sat, 11 Apr 2009 13:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=N9l1tLQ7tGQ/MAzgRCK0LbZ6TI/pyDZJYDFDoaCHikg=; b=gNBfjlxskyrQrw6JlS83ejhTMbsjZUN5jwoQpYB+9LHgSsy9SOo8vA6OsI99BxQS25 GwkRmFwGeptO9Eqn4TLRcHHhnGQWTdDfTr2eCNi9d9CJlfwCHh5+DnDxfVCFqJOdmPWx gWQ/DMJ5iru6AOmprP/fs5RKVQjJRETNUAmxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Aj9FBa86SF/uzKc7pIuZi8C7db6c0rR/l2H19RapQIvYmiZVu2PyxOnCDYlQtZGnrK tqELjSF54AEbWejURiCbsCuzwrhPuuzZCUsBGB68FEBRTDpaM8vPae1ctktoL2iOMMxI NC4tH40xvR8LZGizX2v59UJ/3V5ob0yQZ1NY4= Received: by 10.224.54.65 with SMTP id p1mr4995796qag.99.1239482753664; Sat, 11 Apr 2009 13:45:53 -0700 (PDT) In-Reply-To: <7vprfjf11h.fsf@gitster.siamese.dyndns.org> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Sat, Apr 11, 2009 at 14:22, Junio C Hamano wrote= : > Michael Witten writes: > >> This should make things a little more robust in terms of user input; >> before, even the program got it wrong by outputting a line with only >> "GIT:", which was left in place as a header, because there would be >> no following space character. > > An alternative could be to add an extra space after the "GIT:" on the > lines the compose template generated by this program, but people can = set > their editors to strip trailing whitespaces, so I think yours is a be= tter > approach. =A0I suspect this patch comes from your own experience of g= etting > bitten by this once, perhaps? My first thought was indeed just to add an extra space, but it occurred= to me that it's not easily remembered. Consider the original documentation: > If the body of the message (what you type after the headers and a bla= nk line) only contains blank (or GIT: prefixed) lines the summary won't= be sent >> Also, I cleaned up get_patch_subject(). > > Which is a bit iffy. =A0It does not belong to the primary topic of th= e patch > to begin with, so it shouldn't be in here even if it weren't iffy. I can split it into another patch. > Because "while (<>)" does not localize $_, you are clobbering it in t= he > caller's context. =A0I do not know if any of the the existing callers= cares, > but it is a change in behaviour. How about: while (local $_ =3D <$fh>) Or, in our case, this: while (my $_ =3D <$fh>) In testing these, I came across behavior that I think is incorrect, and= I have a mind to complain about it to the perl guys: # Well! the print `function' doesn't seem to play by the rules. # Example 0 # I expect the output to be: # 1 # 1 # 3 # and I am right! $_ =3D 3; { local $_ =3D 1; print; print "\n"; print $_; print "\n"; } print; print "\n"; ############################################## # Example 1 # I expect the output to be: # 3 # 1 # 3 # But it is: # 1 # 1 # 3 $_ =3D 3; { my $_ =3D 1; print; print "\n"; print $_; print "\n"; } print; print "\n"; ############################################### # Example 2 # I expect the output to be: # 1 # 1 # 3 # and I am right! sub my_print { print(shift or $_); } $_ =3D 3; { local $_ =3D 1; my_print; print "\n"; my_print $_; print "\n"; } my_print; print "\n"; ############################################### # Example 3 # I expect the output to be: # 3 # 1 # 3 # and I am right this time! sub my_print { print(shift or $_); } $_ =3D 3; { my $_ =3D 1; my_print; print "\n"; my_print $_; print "\n"; } my_print; print "\n";