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: Apologia for bzr Date: Sat, 04 Jan 2014 05:34:06 +0900 Message-ID: <87fvp4kdoh.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20140102211452.GA28685@c3po> <83d2k9xx1f.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 1388781272 8931 80.91.229.3 (3 Jan 2014 20:34:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Jan 2014 20:34:32 +0000 (UTC) Cc: esr@thyrsus.com, kfogel@red-bean.com, Toby Cubitt , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 03 21:34:37 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 1VzBRz-0008GS-CA for ged-emacs-devel@m.gmane.org; Fri, 03 Jan 2014 21:34:35 +0100 Original-Received: from localhost ([::1]:51727 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzBRy-00042x-VB for ged-emacs-devel@m.gmane.org; Fri, 03 Jan 2014 15:34:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzBRo-000422-Q4 for emacs-devel@gnu.org; Fri, 03 Jan 2014 15:34:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzBRh-0007Er-F9 for emacs-devel@gnu.org; Fri, 03 Jan 2014 15:34:24 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:55476) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzBRY-0007DR-VD; Fri, 03 Jan 2014 15:34:09 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9798D970A0A; Sat, 4 Jan 2014 05:34:06 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 89C2B1A26F6; Sat, 4 Jan 2014 05:34:06 +0900 (JST) In-Reply-To: <83d2k9xx1f.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:167229 Archived-At: Eli Zaretskii writes: > At least in Emacs we have an excuse that the bulk of the > terminology developed when no other software provided any similar > features; there's no such excuse for git (or bzr or hg). You're wrong about git, you're arguably right about bzr and hg. Git is fundamentally different from bzr and hg, almost as different as it is from CVS and RCS. Git is designed for use cases like "git filter-branch", it's easy enough to implement it as a shell script (though it would be slow), and probably it was prototyped that way (although I would write the prototype in Lisp, not shell). I really wouldn't want to try to do that in hg or bzr: although it could be done, it would be unusably slow (because they don't have a separate index, so the work has to be done in-tree-on-disk, rather than only on metadata in memory). > Anyway, there's a big difference here: in Emacs documentation, > every term is explained before it is used, and rarely used terms > have cross-references to where they are described. I bet you can dip into any number of Info nodes where the terms "buffer" and "window" are used without definition. The git "index" is equally fundamental to git. It's what makes things like "git reset" make sense. It's what explains the sometimes disconcerting behavior of git diff with respect to "git add"ed files. It's what makes staging workflows (which some people love even if you can't figure out why they could love them :-) possible. > > > Here, a typical example from git-commit: > > > > > > DESCRIPTION > > > > > > Stores the current contents of the index in a new commit along with > > > a log message from the user describing the changes. > > > > > > Huh? "Contents of the index"? I used to know what commit was, now I > > > don't. Sure you do; commit hasn't changed. What you now know is what the index is: a data structure that contains the same information as a commit, but isn't a commit and isn't a working tree, either. It has an independent life of its own. Implicitly, it is volatile, and "git commit" makes a persistent record of its current state. Of course hg and bzr use indexes, too, but they're not exposed to the user: they only exist during the process of committing. > You are missing the point: I didn't want a tutorial. I use VCSes for > many years, and dVCSes for some; I already know what it means to > commit a changeset and what is the basic workflow of using a dVCS. But I think you've misstated the case here. Development has workflows, and dVCS usage is adapted to them. It doesn't make sense to talk about "*the* basic workflow of using a dVCS". You're actually talking about *your* basic workflow, and how you use a dVCS in that workflow. Other people's workflows vary wildly, and from the point of view of dVCS usage, they're just as basic. > "Recording a commit"? what's that? And is "commit that has the exact > same tree as its sole parent commit" a complicated way of saying "no > changes since the last commit", or is there some important subtlety > here that I'm missing? It's probably not important to you, so I won't go into detail, but there are several subtleties that are missing from the simple expression "no changes since the last commit". But this is again missing an important point about how git is different: > Even bzr's commit docs does much better: > > --unchanged Commit even if nothing has changed. This makes a lot of sense in Bazaar, because Bazaar makes it hard to work nonlinearly without using multiple workspaces. Nonlinear workflows in a single repo/workspace are what git is designed for. In a nonlinear workflow, "nothing has changed" is meaningless until you answer the question "since *when*?" "The parent commit" is the precise and meaningful answer. > I want some decent reference documentation. AFAICT, you want your dVCS to be Bazaar. Nothing wrong with that (while I really dislike bzr, I don't think it's dead, at least not yet, and that dislike is a personal thing, no reason why you should change your mind). But the overwhelming majority of posters (and I suspect that means the majority of Emacs developers) want git, and git is not, will not be, and should not be, Bazaar. Sorry!