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: conflict state Date: Wed, 09 Apr 2008 20:44:31 -0400 Message-ID: References: <200804061740.m36Hemw8021394@sallyv1.ics.uci.edu> <200804081503.m38F3C3A019899@sallyv1.ics.uci.edu> <200804092139.m39LdEhY009858@sallyv1.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1207788289 16734 80.91.229.12 (10 Apr 2008 00:44:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Apr 2008 00:44:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 10 02:45:20 2008 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.50) id 1Jjkum-0007Y0-5I for ged-emacs-devel@m.gmane.org; Thu, 10 Apr 2008 02:45:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jjku8-0007gn-IH for ged-emacs-devel@m.gmane.org; Wed, 09 Apr 2008 20:44:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jjku3-0007cX-I6 for emacs-devel@gnu.org; Wed, 09 Apr 2008 20:44:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jjku1-0007Ym-GB for emacs-devel@gnu.org; Wed, 09 Apr 2008 20:44:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jjku1-0007Yd-Cy for emacs-devel@gnu.org; Wed, 09 Apr 2008 20:44:33 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182] helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jjku1-00030V-29 for emacs-devel@gnu.org; Wed, 09 Apr 2008 20:44:33 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoFACYA/UfO+KV8/2dsb2JhbACBXKsk X-IronPort-AV: E=Sophos;i="4.25,632,1199682000"; d="scan'208";a="18254180" Original-Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 09 Apr 2008 20:44:32 -0400 Original-Received: from pastel.home ([206.248.165.124]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id QEC16232; Wed, 09 Apr 2008 20:44:32 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id F3E3F8958; Wed, 9 Apr 2008 20:44:31 -0400 (EDT) In-Reply-To: <200804092139.m39LdEhY009858@sallyv1.ics.uci.edu> (Dan Nicolaescu's message of "Wed, 09 Apr 2008 14:39:14 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:94828 Archived-At: >> > A patch to implement the new conflict state is below. Can you please >> > change the magic that runs the resolve command and turns on >> > smerge-mode to use this state instead? >> >> I do not have time to do that right now. > In that case should this code be installed? Yes. >> I'd rather just use the same for edited and conflict if we can't come up >> with a good one. > I'd prefer to have different things for conflict and edited so that they > can be easily distinguished. Agreed, but I think that "no difference" is better than "bad choice" here. Maybe ! should be used for conflicts and remove should use something else. >> This reminds me: we have to be careful that `conflict' is for conflicts >> in the file's contents. Not for conflicts about meta-info (e.g. when >> a file is moved to the same location as some other file, or when a file >> is renamed in two conflicting ways, ...). > Are you sure that is a good idea? For systems that require a "resolve" > command to be run after resolving a conflict, there needs to be some > convenient way run that command. One can resolve the metadata conflict > from within emacs, but then won't be able to have emacs run the resolve > command. I think you read a bit more into my words, than I intended to put. I just want to make sure we keep the distinction between those two in mind. Sometimes they can be treated identically, other times not. The code is currently used and written for "conflicts in the file's content", so we should clearly say that, so that if we introduce code that uses it for metadata-conflicts we hopefully won't forget to add enough comments justifying why it's OK to use it here. >> We should probably arrange to call mark-resolved from vc-after-save >> (after checking that all the conflicts were indeed resolved). > Let's see how this turns out in real life. It seems that there might be > many corner cases to consider... Sure, Stefan