From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: support for git commit --amend/--signoff Date: Fri, 25 Jun 2010 03:16:58 +0200 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 1277428634 18171 80.91.229.12 (25 Jun 2010 01:17:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 25 Jun 2010 01:17:14 +0000 (UTC) Cc: Juri Linkov , =?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?= , emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 25 03:17:13 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 1ORxXa-0000bP-Nx for ged-emacs-devel@m.gmane.org; Fri, 25 Jun 2010 03:17:11 +0200 Original-Received: from localhost ([127.0.0.1]:41765 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ORxXZ-0003HD-S3 for ged-emacs-devel@m.gmane.org; Thu, 24 Jun 2010 21:17:09 -0400 Original-Received: from [140.186.70.92] (port=54232 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ORxXT-0003FG-T0 for emacs-devel@gnu.org; Thu, 24 Jun 2010 21:17:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ORxXT-0001Se-04 for emacs-devel@gnu.org; Thu, 24 Jun 2010 21:17:03 -0400 Original-Received: from smtp-04.vtx.ch ([194.38.175.93]:44338) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ORxXQ-0001SG-SE; Thu, 24 Jun 2010 21:17:01 -0400 Original-Received: from ceviche.home (dyn.83-228-154-025.dsl.vtx.ch [83.228.154.25]) by smtp-04.vtx.ch (VTX Services SA) with ESMTP id 713FC29ACDA; Fri, 25 Jun 2010 03:16:58 +0200 (CEST) Original-Received: by ceviche.home (Postfix, from userid 20848) id 42CE5660E5; Fri, 25 Jun 2010 03:16:58 +0200 (CEST) In-Reply-To: (Dan Nicolaescu's message of "Thu, 24 Jun 2010 19:14:57 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:126381 Archived-At: >>> Can you please show how this is better than adding a single argument >>> to the vc-checkin method? (For which the code already exists). >> It makes more of the state plainly visible to the user, editable with >> Emacs's usual commands, rather than hidden in variables that are much >> more difficult for the user to control. > How is it more difficult to control something that has an explicit > command attached to it? (that you've stated that we need to have > anyway) It's more difficult because you're limited to what the command lets you do, whereas with plain text, you can do anything you like (including running the provided command). >> I.e. it's more Emacsy by keeping things shallow. > That's not quite true for a lot of things we do in Emacs. And in most cases, that is a problem. Sometimes it's justified, and sometimes it's just because noone has gone through the trouble to make it better. >> It means the commit doesn't amend. Same thing if you set your vars >> accidentally or if you call the toggle command accidentally, ... >> >> I really don't see it as a problem. Even if it's done accidentally, >> it's obvious for the user what the behavior will be, since it's written >> in plain text. > Why deal with any potential complications that are not needed at all? What complications are you referring to? >>> --amend and --signoff simply do not fit the header paradigm. >>> Can we please admit that and move on? >> I really don't see it. > Are willing to implement your version and ask users if they prefer it? Don't know. But I don't want the implementation you propose. I want the information to be shallow and readily available for the user to manipulate as she sees fit. Stefan