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: On the popularity of git Date: Sun, 1 Nov 2015 04:24:40 +0900 Message-ID: <22069.5496.845592.116424@turnbull.sk.tsukuba.ac.jp> References: <20151028223252.GD2538@acm.fritz.box> <87vb9qd2h4.fsf@wanadoo.es> <20151028235340.GE2538@acm.fritz.box> <87ziz213wx.fsf@fencepost.gnu.org> <20151029123554.GB2510@acm.fritz.box> <87h9l995ec.fsf@fencepost.gnu.org> <20151029170237.GF2510@acm.fritz.box> <22068.12941.199944.979963@turnbull.sk.tsukuba.ac.jp> <20151031165007.GA20747@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1446319505 19172 80.91.229.3 (31 Oct 2015 19:25:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 31 Oct 2015 19:25:05 +0000 (UTC) Cc: Emacs developers To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 31 20:24:58 2015 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 1Zsblp-0007HL-FO for ged-emacs-devel@m.gmane.org; Sat, 31 Oct 2015 20:24:57 +0100 Original-Received: from localhost ([::1]:56777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zsblo-00049g-Pt for ged-emacs-devel@m.gmane.org; Sat, 31 Oct 2015 15:24:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zsblj-000495-TN for emacs-devel@gnu.org; Sat, 31 Oct 2015 15:24:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zsble-000734-RV for emacs-devel@gnu.org; Sat, 31 Oct 2015 15:24:51 -0400 Original-Received: from turnbull.sk.tsukuba.ac.jp ([130.158.96.25]:37898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zsble-000704-Ai for emacs-devel@gnu.org; Sat, 31 Oct 2015 15:24:46 -0400 Original-Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.86) (envelope-from ) id 1ZsblZ-0003dh-2a; Sun, 01 Nov 2015 04:24:41 +0900 In-Reply-To: <20151031165007.GA20747@acm.fritz.box> X-Mailer: VM undefined under 21.5 (beta34) "kale" 698a9aa86de4 XEmacs Lucid (x86_64-apple-darwin14.5.0) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: steve@turnbull.sk.tsukuba.ac.jp X-SA-Exim-Scanned: No (on turnbull.sk.tsukuba.ac.jp); SAEximRunCond expanded to false X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 130.158.96.25 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:193026 Archived-At: Alan Mackenzie writes: > No, I don't want to become a VCS expert (or, as you put it, "study" my > VCS). I studied hg, and it fell into place, mentally, without trouble. Weird. I studied all three (in order to help write PEP 374), and they just aren't different for any of the Python-Dev workflows that we compared. At the time it took 0.1 revolutions of Halley's Comet to checkout Python with bzr; obviously that was out. The people who just hated git but couldn't explain why, plus the dogfooding principle (hg is written in Python), carried the day. > I just want to be a user, as one can quite easily be a user of hg > or bzr. Being a user of git involves learning its internal > structures. No, it doesn't. The workflows for git looked just like the workflows for hg and bzr, *unless you want to modify a DAG at internal nodes* (but there were no such tasks on the list for PEP 374). Then the workflows are very different (basically nonexistent in hg and bzr at that time). In any case, you already know the internal structure of git because it's the same as a Lisp list (with a slight variation to account for merges). The commands for working with it have different names (commit for cons, reset for setq), that's all. > (Note the people recently emphasising the internal representation > of a git branch to me, talking about pointers to its tip, and so > on. Yeah, and a year ago I would have been posting the same stuff. I know now that that's like "messing around with Jim"[1], because: > I really don't want to have to know about such stuff.) > It is evident that when the UI for git was "designed" nobody of any > experience (or taste) in UIs was involved in the process. Nobody > knew when to say "stop!". So there are _lots_ of commands, and the > ones used most often have 20, 30, 50 options Sounds just like Emacs, except that git is a whole lot more popular. > to learn about, Huh? If you don't want to learn about them, don't. Ask a friend who uses git how to do it. You do have git-using friends (probably about 100,000 of them -- all them cc-mode users!) > some of which do several distinctly different things (e.g. git > checkout). OK, you got me there. You have a choice: learn all the variations on checkout, or learn some internals so you can use reset. Not attractive. > If the git team had paid as much attention to UI as they did to > elegant internal structures, they would have had a world beater of > a program. Er, where have you been for the last 5 years? They *do* have a world beater of a program. Compare user population with, uh, Emacs. > Not at all. There are 20, 30, or 50 options which all consciously have > to be omitted. Which 6 letters in the word "option" didn't you read as you typed it? Come on, Alan, you've gone past petulant with that one. I really don't get this; in my workflow I almost never use options in git, except for - for log, -m and occasionally -a when committing, --hard for reset, -l and -f for tag and branch, and -b for checkout, all of which have important semantics and are pretty easy to understand IMO. What other git options do you need for your workflows? > > [2] It occurs to me that one of the things I hated about both bzr and > > hg was that a bare "$VCS commit" commits everything. > > But in both of them, the commit message template informed you which > files were being committed, giving you the opportunity to abort. I never see that template: I use "-m" (command line) or "-F ,msg" (in XEmacs). > > That is *almost never* TRT for my workflow. But I suspect that Alan > > loves that feature, since he has a religious objection to commiting a > > workspace that hasn't been polished to an optically perfect surface. > > What, you mean as opposed to committing any old rubbish at the drop of a > hat? Yes. Heck, I had this: (defun sjt/git-auto-commit () (let ((file (file-name-nondirectory (buffer-file-name)))) (shell-command (format "git commit -m \"Auto-commit %s.\" %s" file file)))) on after-save-hook for a while. I admit it stopped being amusing pretty quickly (rebase -i didn't exist back then). Instead, I just taught myself to commit frequently enough that if I get confused about what I'm doing I can usually reconstruct thought processes by looking at the diffs. BTW, although I don't care if those "interim" commits become public, if I did care it's easy enough to "squash" the interim branch into a single commit on trunk, and optionally delete that interim branch. > The vagueness and uncertainty introduced by git's two stage > committing, I don't understand. If you don't have any added or removed files for your "polished" commit, you just do "git commit --all". If you do, you do "git add --all; git commit". This isn't much different from what you have to do with bzr or hg, except that you wouldn't need --all on commit for the first version. It's a bit more typing than for hg or bzr which default to committing everything modified, but that's always an issue when users disagree about defaults: the minority loses. Footnotes: [1] https://www.youtube.com/watch?v=-4qUXcXuMSE