From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Referring to revisions in the git future. Date: Wed, 29 Oct 2014 12:37:18 +0100 Message-ID: <87tx2n9kep.fsf@fencepost.gnu.org> References: <20141028223312.GB6630@acm.acm> <87fve7b6p7.fsf@fencepost.gnu.org> <20141029111837.GA2953@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414582666 15251 80.91.229.3 (29 Oct 2014 11:37:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Oct 2014 11:37:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 29 12:37:40 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 1XjRZI-0000Ut-88 for ged-emacs-devel@m.gmane.org; Wed, 29 Oct 2014 12:37:36 +0100 Original-Received: from localhost ([::1]:45120 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjRZH-0006qA-TJ for ged-emacs-devel@m.gmane.org; Wed, 29 Oct 2014 07:37:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33114) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjRZ3-0006q5-9b for emacs-devel@gnu.org; Wed, 29 Oct 2014 07:37:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XjRZ1-0000o3-U0 for emacs-devel@gnu.org; Wed, 29 Oct 2014 07:37:21 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjRZ1-0000nz-Qc for emacs-devel@gnu.org; Wed, 29 Oct 2014 07:37:19 -0400 Original-Received: from localhost ([127.0.0.1]:47052 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjRZ0-0007CJ-Pp; Wed, 29 Oct 2014 07:37:19 -0400 Original-Received: by lola (Postfix, from userid 1000) id 1FA71E062F; Wed, 29 Oct 2014 12:37:18 +0100 (CET) In-Reply-To: <20141029111837.GA2953@acm.acm> (Alan Mackenzie's message of "Wed, 29 Oct 2014 11:18:37 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:175975 Archived-At: Alan Mackenzie writes: > Hello, David. > > On Wed, Oct 29, 2014 at 09:50:28AM +0100, David Kastrup wrote: >> Alan Mackenzie writes: > >> > Hello, Emacs. > >> > We are switching to git, soon. > >> > git doesn't have revision numbers. Instead it uses cryptic >> > identifiers, which are not very useful in day to day conversation. A >> > bit like in George Orwell's "Newspeak", where lingusists constantly >> > removed words and meanings so as to render certain notions literally >> > inexpressible, we seem to be faced with the same situation. > >> > On this list, one quite often sees statements such as: > >> > "That was fixed in revision 118147, have you updated since then?" > >> > or > >> > "The bug seems to have been introduced between 118230 and 118477. >> > Maybe you could do a bisect to track it down.". > >> So what are people going to do with this kind of information? >> Copy&paste it into some command line. A 40-letter string works just as >> well as a 6 letter string for that. > > Copy&paste using a mouse is a tedious operation which interrupts > workflow. So don't use a mouse. > A number like 118230 can be easily memorised and typed in to a command > line. Frankly, memorizing something like revision ids is error prone and dangerous. If you memorize the first 6 characters of a commit id instead, at least Git will complain if that identifies no unique commit. > What else am I going to do with the information? A revision number > contains useful meta-information: how old the revision is (more or less), > and whether it comes before or after another revision (more or less). That's the kind of stuff I'd rather ask my version control system. > In the above "fancy doing a bisect?" example, it's immediately clear > that the bisect operation is going to be taking around 7 or 8 > repetitions, that clarity being more immediate and subconscious than > calculated. One can estimate, quasi subconsciously, whether the > tedium involved in the bisection would be well spent, or whether some > other approach would be better. Well, feed those numbers to git bisect, and it will tell you right away how many steps it will take. Exactly. > A revision number tells you how old the repository is. With 118230, > the repository is clearly decades old. With 729, it might be as young > as a few months. I don't see you appending your birth date to your name, either. Basically you are complaining that the commit SHA1 only provides the commit SHA1 without additional literary value that one can approximately deduce when brooding for hours over it rather than asking the version control system. But it is not intended to be a conversation piece. > With revision hashes, all that information is absent. To get it, one > is forced to enter tedious command line commands, likely having to use > a mouse to cut and paste the hash - twice. Keyboard exists. > It is analogous to being able to refer to people by their names, > compared with having to use some sort of random identifier. If you become acquainted with a particular revision number to a degree that you develop a personal relation to it, chances are that this commit was a bad idea. Also chances are that you'll start recognizing the SHA1 after getting to see it for the twentieth time. > Having revision numbers clearly works very well. That reminds me of the rule-of-thumb for discovering errors in mathematical proofs: just look for the first occurence of any of "clearly", "trivially", "obviously", "it can be easily shown". > bzr and hg both have them in addition to the universe-unique hashes. > git is missing this useful feature. And git clearly works very well since it is being used in large-scale non-trivial projects with thousands of developers. Feel free to use "git describe" yourself for getting a "human-readable" "revision number". But don't expect many others to follow that practice enthusedly. -- David Kastrup