From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: No commit in vc? Date: Fri, 29 Jan 2010 13:05:41 +0100 Message-ID: <87iqalru96.fsf@telefonica.net> References: <4B613BFB.2000107@swipnet.se> <87bpgev5bk.fsf@telefonica.net> <4B618AA4.1040403@swipnet.se> <87vdemtk4g.fsf@telefonica.net> <837hr23wrs.fsf@gnu.org> <87eilat62r.fsf@telefonica.net> <83eilat4g7.fsf@gnu.org> <873a1qt32z.fsf@telefonica.net> <83aavyt0bt.fsf@gnu.org> <201001290200.o0T200xh010567@godzilla.ics.uci.edu> <83y6jhs2b6.fsf@gnu.org> <201001290940.o0T9e0br025585@godzilla.ics.uci.edu> <87r5p9rxun.fsf@telefonica.net> <83vdelrx60.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1264766787 32066 80.91.229.12 (29 Jan 2010 12:06:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jan 2010 12:06:27 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 29 13:06:24 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 1NapcG-0002Ja-3K for ged-emacs-devel@m.gmane.org; Fri, 29 Jan 2010 13:06:24 +0100 Original-Received: from localhost ([127.0.0.1]:54029 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NapcF-0006Ns-KL for ged-emacs-devel@m.gmane.org; Fri, 29 Jan 2010 07:06:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Napc9-0006Nj-6f for emacs-devel@gnu.org; Fri, 29 Jan 2010 07:06:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Napc4-0006Mu-6V for emacs-devel@gnu.org; Fri, 29 Jan 2010 07:06:16 -0500 Original-Received: from [199.232.76.173] (port=57676 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Napc4-0006Mr-0F for emacs-devel@gnu.org; Fri, 29 Jan 2010 07:06:12 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:58204) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Napc2-0003WB-UU for emacs-devel@gnu.org; Fri, 29 Jan 2010 07:06:11 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Napby-00025A-38 for emacs-devel@gnu.org; Fri, 29 Jan 2010 13:06:06 +0100 Original-Received: from 92.red-88-24-231.staticip.rima-tde.net ([88.24.231.92]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Jan 2010 13:06:06 +0100 Original-Received: from ofv by 92.red-88-24-231.staticip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Jan 2010 13:06:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 31 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 92.red-88-24-231.staticip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) Cancel-Lock: sha1:NHkkrbsJYOglXR8xKq2bfRTg08o= 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:120645 Archived-At: Eli Zaretskii writes: >> Maybe it is a good idea to display the condition that there are pending >> merges > > Display how? If in the modeline, then that indicator might not be > prominent enough to draw the attention. Perhaps on the top of the buffer, using a prominent face. > I would like to repeat my suggestion to explicitly ask whether to > commit after a merge that results in pending merges, with the answer > defaulting to "yes". Well, in bzr (contrary to git) all merge operations result in pending merges. Added to this, you are supposed to review the results, not only in case there are conflicts, but in general (that's what bzr people say to explain why all merges require an explicit commit). Finally, AFAIK VC-dir has no support for executing a `bzr merge'. > If the user says "no", they know what they are > doing, and will not forget to commit after they do whatever it was > that caused them not to commit right away. For others, it is a safe > bet that they don't have enough bzr flowing in their blood to > understand that they will be in trouble if they don't commit soon, so > we will be doing them a favor by suggesting to commit. What VC-dir could do is to warn the user if there is a pending merge and he tries to do a selective commit. For me it is good enough what it does now: try to execute the command and show the error message reported by bzr.