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 01:02:36 +0900 Message-ID: <22068.58908.337055.881648@turnbull.sk.tsukuba.ac.jp> References: <20151028192017.GC2538@acm.fritz.box> <87k2q6wy8p.fsf@linaro.org> <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> <83611nzbqr.fsf@gnu.org> 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 1446307386 5608 80.91.229.3 (31 Oct 2015 16:03:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 31 Oct 2015 16:03:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 31 17:03:01 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 1ZsYcO-0003ZC-MP for ged-emacs-devel@m.gmane.org; Sat, 31 Oct 2015 17:03:00 +0100 Original-Received: from localhost ([::1]:56275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsYcN-0005Th-I1 for ged-emacs-devel@m.gmane.org; Sat, 31 Oct 2015 12:02:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsYc9-0005Tc-79 for emacs-devel@gnu.org; Sat, 31 Oct 2015 12:02:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZsYc8-0006Wy-65 for emacs-devel@gnu.org; Sat, 31 Oct 2015 12:02:45 -0400 Original-Received: from turnbull.sk.tsukuba.ac.jp ([130.158.96.25]:36260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsYc4-0006WR-51; Sat, 31 Oct 2015 12:02:40 -0400 Original-Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.86) (envelope-from ) id 1ZsYc0-0001nZ-Hi; Sun, 01 Nov 2015 01:02:36 +0900 In-Reply-To: <83611nzbqr.fsf@gnu.org> 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:193019 Archived-At: Eli Zaretskii writes: > The truth is that "$VCS commit" committing all the changes _is_ > TRT. Why? Because you're a former Department of Defense contractor used to MIL-STD-498 processes and only commit after getting three signatures on a paper form anyway? Or you're Alan Mackenzie, Eli Zaretski, or Richard Stallman, capable of effortlessly keeping a clean workspace without ever having those embarrassing extraneous changes in it. > because all the other VCSes before and after Git do that, As David points out SCCS, RCS, and CVS didn't do that. SCCS and RCS *could not*. I don't recall what larch and its successors, or Bitkeeper, did, but I don't think they did, either. > and because that's what a mere human would expect. I love you too, Eli, but I'm not a genius programmer, and I'm just disciplined enough that I can do without "git rebase -i" before pushing -- but only because "git commit" doesn't DTWT. I actually have had to checkout the previous version into a new workspace and cp the changed files over, then recommit (and delete the polluted branch) before bzr and hg got their respective uncommit commands. (There probably was a better way but I was offline and impatient. And as much as I dislike that style, it hasn't prevented me from learning "hg strip" and "bzr uncommit" respectively.) > (I've made me an alias to do just that.) > > More generally, Git's main problem is that it breaks almost every > human habit gained with the other VCSes: instead of an easily > remembered numerical version IDs True, for short-term memory. Because I have to ask what revision I'm on now and then do the relevant subtraction most of the time. I never have to do that with git. I'm sure bzr and hg have shortcuts for that now, but now I use those tools rarely enough that I needn't bother finding a better way. > you have those inhuman hashes Of course they're inhuman. They're intended to be an approximation to Goedel numbers. Even Goedel didn't usually write formulas that way (although Ramanujan may have ;-). And SHAs are way better than those Bizarre revids[1], which are the only stable way to refer to a Bazaar revision. > and the HEAD^^^^ and {m,n} thingies, You must detest Lisp, then, with its `cddr' and `nth'. That's all that HEAD~N means, you know; (nth N HEAD). When I realized that, that's when I fell in love with git. The rest of the DAG traversal algebra doesn't disturb me, I just ignore it (except for the occasional use of @{N} and *very* rare uses of ^ other than as an abbreviation for ~1). > instead of being able to say "commit" and commit the entire > changeset you need "git add" first, etc. etc. Nonsense. "git commit -a ..." has always committed all modified files, and as far as I know there is no VCS that automatically adds unknown files to a commit (even if they're not vcs-ignored). > _That_ is the single most important problem with Git that begets all > the other problems in usability and user-friendliness: it doesn't give > a damn about established VCS practices and mnemonics, and breaks them > all one after another. It does that consciously and on purpose. And > after all that, it expects me to like it. Ha! Now, now. Don't anthropomorphize software. The next thing you know, you'll be opposing the GPL because "software wants to be free". Seriously, I don't see any reason why *everybody* should like git. But I can see lots of reasons why a whole lotta people would love it, warts and all. And ... I can see no good reason for Alan et al. to cause themselves pain repeatedly by not learning enough about git to use it effectively. They can learn, as you have. They just refuse to. Footnotes: [1] Which made some sense in Arch. But they're just weird in Bazaar.