From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: git pull fails with merge conflicts. How can this possibly happen? Date: Sat, 15 Nov 2014 11:56:36 +0100 Organization: Organization?!? Message-ID: <874mu0ohp7.fsf@fencepost.gnu.org> References: <20141114183737.GB3168@acm.acm> <5466517B.50705@porkrind.org> <20141114215404.GD3168@acm.acm> <838ujchods.fsf@gnu.org> <8761egx1k2.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416049033 25571 80.91.229.3 (15 Nov 2014 10:57:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Nov 2014 10:57:13 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 15 11:57:05 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xpb2P-0003s7-BD for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 11:57:05 +0100 Original-Received: from localhost ([::1]:39813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpb2P-0005EA-2I for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 05:57:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpb2F-0005Dt-Ja for emacs-devel@gnu.org; Sat, 15 Nov 2014 05:57:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xpb29-00081H-IN for emacs-devel@gnu.org; Sat, 15 Nov 2014 05:56:55 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:38304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpb29-00081D-CB for emacs-devel@gnu.org; Sat, 15 Nov 2014 05:56:49 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xpb28-0003ng-8S for emacs-devel@gnu.org; Sat, 15 Nov 2014 11:56:48 +0100 Original-Received: from x2f520ac.dyn.telefonica.de ([2.245.32.172]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Nov 2014 11:56:48 +0100 Original-Received: from dak by x2f520ac.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Nov 2014 11:56:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 52 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f520ac.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:Wsyg9ZpxXXQnJDTTZLqkYTF6Cf0= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177162 Archived-At: "Stephen J. Turnbull" writes: > This "confusion" I still don't get. Git semantics are singly-linked > list semantics: commit ~ cons (object), tree ~ array of tree-or-blob, > blob ~ atom, ref ~ list-valued symbol, branch = ref where the commit > command has push (cl-macro) semantics, tag = ref where the commit > command has cons (primitive function) semantics. Everything else > follows from list-traversing semantics, rather than the array > reference semantics that svn and bzr provide with refnos. Only merges > ("cons with multiple parents") fail to follow the pattern, but I've > never heard anyone complain that merges are particularly hard to > understand.[1] > > What's so hard about list semantics for an Emacs developer? A list is a high-level concept. This high-level concept as a sequence of items does not result in semantics like the support of shared tails. Indeed, only singly-forward-linked lists with individually reference-managed list members support these particular semantics seamlessly: they are not "list semantics" but are emergent semantics from a very particular set of list implementations. The Git reference system can be described in terms of non-circular versions of LISP lists. But in reality we are not talking about "list semantics" here. What you call "list semantics" are "finite directed graph" semantics, and Git uses the subset of "finite directed acyclical graph" semantics. That LISP uses directed acyclical graphs for representing finite lists is an implementation detail, not a high-level description of what lists are, namely a sequence of items. And LISP lists are a subset, since they are either a _finite_ or a terminally cyclical sequence of items. LISP cannot represent things like the list of natural numbers. So LISP's _implementation_ of lists can be mapped somewhat comfortably to Git's use of finite directed acyclical graphs. That's an isomorphism. Which is nice if you want to map a Git repository to Emacs data structures. It does not mean that Git uses "list semantics", however. Nor does it mean that Git's behavior can well be described or even implemented in terms of _lists_ rather than of a particularly organized tree of conses. Try, for example, describing the structure of a Git repository in terms of a C++ STL list type rather than of LISP "lists". Doesn't work. The talk about "list semantics" is a red herring even though any traversal along the edges of a finite directed acyclical graph ends up being a list. -- David Kastrup