From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: git pull fails with merge conflicts. How can this possibly happen? Date: Sat, 15 Nov 2014 12:54:39 +0200 Message-ID: <83sihkg2ds.fsf@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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1416048917 23990 80.91.229.3 (15 Nov 2014 10:55:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Nov 2014 10:55:17 +0000 (UTC) Cc: acm@muc.de, david@porkrind.org, emacs-devel@gnu.org, yuri.v.khan@gmail.com To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 15 11:55:10 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 1Xpb0X-00039Y-R6 for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 11:55:09 +0100 Original-Received: from localhost ([::1]:39810 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpb0W-0004jd-UD for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 05:55:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpb0Q-0004h8-54 for emacs-devel@gnu.org; Sat, 15 Nov 2014 05:55:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xpb0K-0007Au-Gm for emacs-devel@gnu.org; Sat, 15 Nov 2014 05:55:02 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:34370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpb0K-0007Ao-8N for emacs-devel@gnu.org; Sat, 15 Nov 2014 05:54:56 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NF200500TYAAE00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 15 Nov 2014 12:54:54 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NF200505UBH9D30@a-mtaout22.012.net.il>; Sat, 15 Nov 2014 12:54:54 +0200 (IST) In-reply-to: <8761egx1k2.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:177161 Archived-At: > From: "Stephen J. Turnbull" > Cc: Yuri Khan , > acm@muc.de, > david@porkrind.org, > emacs-devel@gnu.org > Date: Sat, 15 Nov 2014 18:20:29 +0900 > > > Mind you, I come from the same population of the confused whom you are > > trying to teach here: my mind still doesn't wrap itself easily around > > Git semantics, > > This "confusion" I still don't get. Git semantics are singly-linked > list semantics: I think we have different notions of "semantics", see below. > 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? First, your list of primitive objects is already an obstacle: it's too long, and the objects are themselves too abstract. As a user of a VCS, I care about commits, branches, and merges, and my notion of a "tree" is just what I see in the file system. I don't want to know about anything else, at least not in the beginning. However, Git docs keep pushing those other objects into my face on every turn. Second, too many things in Git are different, or are done differently, or have different effect from their namesakes in other VCSes (a.k.a. "have different semantics". At times, I have a distinct feeling that Someone(TM) made a conscious effort to confuse me by picking up a different semantics. Examples: . "git checkout" is not what a "checkout" means or does in any other VCS I know of. Moreover, it has several different meanings and effects, one of them being "revert to the last version", for example. . "bzr pull" doesn't commit; "git pull" does. Likewise for "merge". (AFAIK, svn and hg both behave like bzr.) One effect of that is that you need to remember to use -e if you want to add something to the commit log message when you merge or cherry-pick. . the inhumanely complex way of specifying past commits. I miss the simplicity of -n..-m; the replacement @~n..@~m is more to type and remember; the similar @{n}..@{m} has a subtly different meaning. What's more, the documentation doesn't help by giving you examples of specs you'd frequently use, but instead insists on formally describing the syntax, leaving the rest to you to figure out. The result is that I'm not even sure I figured out the "@~n..@~m" spec correctly (did I?). The other result is that to see the diffs of the last commit, it is much easier to use "git show" than the more obvious "git diff". I could go on, but I hope you see the point: I don't want to study Git as deep as you seem to imply. Git is just a tool for me, and a minor one at that, not unlike Grep or 'locate'. Most of my work on Emacs is not with Git, even though I need sometimes to do some VCS forensics in order to see the history of some change. I just want to use Git seamlessly. My problem, to sum it up, is that there are too many things I need to re-learn from scratch, and too much muscle memory I need to un-learn. > [1] Granted, submodules *are* hard; it's not just that tree is > generalized to array of tree-or-blob-or-commit, but that commits also > change semantics when used in submodules. But we're not talking about > submodules in Emacs yet. I think we are, in the ELPA related discussions. But maybe I'm confused about that, too.