From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: support for git commit --amend/--signoff Date: Thu, 24 Jun 2010 17:18:42 -0400 Message-ID: References: <87hblavx6f.fsf@mail.jurta.org> <874oh94kdh.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1277414338 7261 80.91.229.12 (24 Jun 2010 21:18:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 24 Jun 2010 21:18:58 +0000 (UTC) Cc: Juri Linkov , =?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?= , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 24 23:18:55 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ORtow-00015M-2E for ged-emacs-devel@m.gmane.org; Thu, 24 Jun 2010 23:18:50 +0200 Original-Received: from localhost ([127.0.0.1]:44716 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ORtov-0004hX-Ee for ged-emacs-devel@m.gmane.org; Thu, 24 Jun 2010 17:18:49 -0400 Original-Received: from [199.232.76.173] (port=49945 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ORtoq-0004gA-C9 for emacs-devel@gnu.org; Thu, 24 Jun 2010 17:18:44 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1ORtop-0004fU-7l for emacs-devel@gnu.org; Thu, 24 Jun 2010 17:18:44 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:54074) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ORtoo-0004fQ-Vq for emacs-devel@gnu.org; Thu, 24 Jun 2010 17:18:43 -0400 Original-Received: from dann by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1ORtoo-0002nK-CU; Thu, 24 Jun 2010 17:18:42 -0400 In-Reply-To: (Stefan Monnier's message of "Thu\, 24 Jun 2010 23\:03\:22 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:126374 Archived-At: Stefan Monnier writes: >>> Oh, that's why you tend to treat it like --amend. I see it's a problem, >>> indeed, but I don't think that storing it into a buffer-local variable >>> is a good answer. I'd rather have a "Sign-Off: yes" (you can still > >> But that means that >> Sign-off: no | off >> will still add --signoff. > > Not at all. The code gets to decide which values mean "add a --signoff > argument". I'd start with only accepting "yes". > >> Which is confusing and wrong. > > It would be indeed, but that's not what I'm suggesting we do. > >> More >> Sign-off: foo@bar.com >> gives the impression that it will use foo@bar.com to sign off, but that's not the case. > > For the values other than "yes" we can highlight them with > font-lock-warning-face and the backend can prompt the user when faced > with such unclear values. We should also do something similar for > unknown values of the "Fixed:" field, BTW. So now let's go back to the origin of this: there's a lot of code that needs to be added just to deal with the various possibilities for just the Signoff header, and even more for Ammend. Can you please show how this is better than adding a single argument to the vc-checkin method? (For which the code already exists). >>> Why not show it inside the buffer (e.g. in the header ;-) instead? >> Because we want to insert the previous log when using --amend, so it's >> better to use a command instead of a header. > > The question is not "a command vs a header" but "a variable vs > a header". In both cases we will want to provide a command (which will > fetch the previous log, etc...). So what happens if one deletes the Ammend: header? Accidentally or not? --amend and --signoff simply do not fit the header paradigm. Can we please admit that and move on?