From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Obscure error/warning/information message from git pull Date: Wed, 19 Nov 2014 07:59:44 +0900 Message-ID: <87389gunbz.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20141114120604.GA3859@acm.acm> <87389mkjwo.fsf@thinkpad-t440p.tsdh.org> <20141114141434.GM3565@embecosm.com> <20141114180521.GA3168@acm.acm> <20141114230235.GF3168@acm.acm> <20141117141123.GA4294@acm.acm> <83lhn89zxn.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1416351621 21888 80.91.229.3 (18 Nov 2014 23:00:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2014 23:00:21 +0000 (UTC) Cc: Sergey Organov , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 19 00:00:13 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 1Xqrkr-000349-9O for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 00:00:13 +0100 Original-Received: from localhost ([::1]:55814 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqrkr-0002G8-0s for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 18:00:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqrkg-0002DX-V8 for emacs-devel@gnu.org; Tue, 18 Nov 2014 18:00:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqrkZ-0002Mc-G1 for emacs-devel@gnu.org; Tue, 18 Nov 2014 18:00:02 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:35071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqrkR-0002Lb-7c; Tue, 18 Nov 2014 17:59:47 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id E11021C3965; Wed, 19 Nov 2014 07:59:44 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id BD02E1A2844; Wed, 19 Nov 2014 07:59:44 +0900 (JST) In-Reply-To: <83lhn89zxn.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:177692 Archived-At: Eli Zaretskii writes: > > Git itself has no "branches" that are "active lines of development" > > in its data model. > > Git might not have it, but we its users do. True, but in practice there are *no* VCSes that have "active lines of development". They have branch heads (aka "tips" in some VCSes), and the VCS will just extend the branch from there. Some VCSes make it hard to establish a new head, and bitch unmercifully if you leave it unmerged. But the active line of development is still in your head -- even Bazaar doesn't try to keep you from committing arbitrary crap to the mainline. It just tries to "encourage" you to commit arbitrary crap to the mainline, or alternatively postpone nonlinear work. If that works for you, good for you, but git is explicitly designed to avoid that constraint. That constraint is fine for projects where you can move ahead in a straight line, and Emacs's workflow has been designed that way (eg, only one supported version plus a free-for-all on trunk). A lot of us find that chafing, and enjoy the freedom that git provides to unify our nonlinear practices with *one* concept that I might call "focus of development". Git's notion of branch ref is an excellent approximation to focus of development in my experience, and I use it a *lot*. The analogy to Emacs's "modeless editing"[1] is quite appropriate, I think. > > Kinda like "everything is a buffer" in Emacs. > > But everything is not a buffer in Emacs. There are other objects as > well, most of them quite different from buffers. You're missing the point. There are other objects in *Lisp*, but most things users do are operations on buffers as far as the UI is concerned. Similarly, there are lots of things in git besides branch refs, but most things users do operate on branch heads. It's both an approximation to git and an approximation as an analogy of git to Emacs, but there's some truth there. Footnotes: [1] Ie, no division into "insert mode" and "edit mode".