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: Thu, 20 Nov 2014 12:01:25 +0900 Message-ID: <87ioiatw1m.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20141114180521.GA3168@acm.acm> <20141114230235.GF3168@acm.acm> <20141117141123.GA4294@acm.acm> <83lhn89zxn.fsf@gnu.org> <83bno49xtw.fsf@gnu.org> <20141118224326.GA5167@acm.acm> <87mw7n8k0f.fsf@Rainer.invalid> <837fyr88mc.fsf@gnu.org> <83y4r76n86.fsf@gnu.org> <87k32rgdm4.fsf@fencepost.gnu.org> <83mw7n6j83.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 1416452540 676 80.91.229.3 (20 Nov 2014 03:02:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Nov 2014 03:02:20 +0000 (UTC) Cc: David Kastrup , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 20 04:02:12 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 1XrI0Z-0004j3-U3 for ged-emacs-devel@m.gmane.org; Thu, 20 Nov 2014 04:02:12 +0100 Original-Received: from localhost ([::1]:33301 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrI0Z-0005Kx-6p for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 22:02:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrI0F-0005Kb-DX for emacs-devel@gnu.org; Wed, 19 Nov 2014 22:01:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrI07-0005fi-Sl for emacs-devel@gnu.org; Wed, 19 Nov 2014 22:01:51 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:58090) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrHzs-0005bt-27; Wed, 19 Nov 2014 22:01:28 -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 4D1361C3AAC; Thu, 20 Nov 2014 12:01:25 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4222A1A2844; Thu, 20 Nov 2014 12:01:25 +0900 (JST) In-Reply-To: <83mw7n6j83.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:177844 Archived-At: Eli Zaretskii writes: > > Branches are ephemeral, the commit graph is static. Equating the two > > will not do your understanding favors. > > Didn't expect to hear this from you. Others, yes, but not you. David tends to be overly emphatic. In this thread AIUI we're trying to help existing Emacs developers who find git to be new and confusing. Eli is proposing that *they* adopt the abstraction of "branch" as being a structure defined by transitive closure of the parent relation that "really exists" in the DAG, *with* a "branch ref" as a (possibly mutable) name that is an *essential* "handle" to the branch for operations such as commit and merge. I think it's reasonable to say that for the purposes of these developers, that is useful and unlikely to cause them any harm. During the transition period (broadly speaking; I wouldn't be surprised if people are still digging patches out of dormant bzr branches in late 2016!), it is highly unlikely that they will encounter any behaviors in the public Emacs repos (renamed branches, branches that have a social identity with a different extent from master..branch in the DAG, etc) that violate the "branch ref + reachable commits" model. This isn't as restrictive a model as the one Alan Mackenzie has in mind, with branch as an actual queryable object with persistent identity and metadata. The branch-is-object model is clearly wrong in git. In other words, branches are implemented in a way that makes them ephemeral in principle, but you won't need to notice that in Emacs practice (and Eli advocates ignoring that fact). On the other hand, the ephemerality of branches is one of the principal sources of power in git. I agree entirely with David that confusing the DAG of commits with a collection of branches means you lose a lot of the benefits of git, and makes it very hard to use git as effectively as you used branch-oriented VCSes.