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: Fri, 11 Jun 2010 13:34:30 -0400 Message-ID: References: <87hblavx6f.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1276277682 3670 80.91.229.12 (11 Jun 2010 17:34:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 11 Jun 2010 17:34:42 +0000 (UTC) Cc: Juri Linkov , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 11 19:34:40 2010 connect(): No such file or directory 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 1ON87r-0007y2-Dd for ged-emacs-devel@m.gmane.org; Fri, 11 Jun 2010 19:34:39 +0200 Original-Received: from localhost ([127.0.0.1]:35011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ON87q-0003My-Rv for ged-emacs-devel@m.gmane.org; Fri, 11 Jun 2010 13:34:38 -0400 Original-Received: from [199.232.76.173] (port=36204 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ON87l-0003Mh-2y for emacs-devel@gnu.org; Fri, 11 Jun 2010 13:34:33 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1ON87j-00083K-Bt for emacs-devel@gnu.org; Fri, 11 Jun 2010 13:34:32 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:53824) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ON87j-00083G-5C for emacs-devel@gnu.org; Fri, 11 Jun 2010 13:34:31 -0400 Original-Received: from dann by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1ON87i-0007fi-DB; Fri, 11 Jun 2010 13:34:30 -0400 In-Reply-To: (Stefan Monnier's message of "Fri\, 11 Jun 2010 10\:18\:34 -0400") 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:125755 Archived-At: Stefan Monnier writes: >> For --amend I think we should have a different mechanism that does not >> involve editing the text in the *VC-log* buffer, it's a more >> destructive operation and it's not a good idea to allow the user to do >> it by mistake by just placing an Amend: line in the buffer. > > You might be right, but I don't think it would be terribly bad to have it > be editable in the buffer (after all it's also just an "--amend" away when > committing on the command line). > > I'm not sure what UI you're considering to use and what users would > want, because I've never used Git's amend feature. But I think it > should be considered in the light of similar functionality in other VCS, > such as maybe "cvs admin -m" and DaRCS's "amend-record". > > For PCL-CVS what I offered was a way to edit a log-message (typically > called from the log-view buffer). But admittedly, "cvs admin -m" is > a fairly different beast from Git's amend. We already have a UI for that in VC: from the log buffer you can use "e" to edit the commit log. git commit --amend is different, it can be used to add more files to the same commit, and it can only affect the last commit. > If we only consider Git's and DaRCS's forms of amend, I'd say that the > "Amend:" header might be a good approach, and that it should specify the > revision/patch that's amended. So for Git, you could have a command > that inserts "Amend: " and then the backend could check that the > SHA-1 is the right one (which would avoid accidental use). That looks like a bad UI: the user sees information that is unnecessary, and might feel compelled to verify if the sha1 is indeed to correct one (i.e. time wasted for no good reason). Other VCs have commands that we might want to support in a similar manner, for example: hg has --close-branch So besides the markup in the VC-log buffer, we need another way to pass arguments to the commit command.