From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Referring to revisions in the git future. Date: Tue, 28 Oct 2014 23:54:19 +0100 Message-ID: <87tx2n7qlg.fsf@wanadoo.es> References: <20141028223312.GB6630@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1414536902 30153 80.91.229.3 (28 Oct 2014 22:55:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Oct 2014 22:55:02 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 28 23:54:54 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 1XjFf9-0007Ew-Df for ged-emacs-devel@m.gmane.org; Tue, 28 Oct 2014 23:54:51 +0100 Original-Received: from localhost ([::1]:41726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjFf9-0002oP-4z for ged-emacs-devel@m.gmane.org; Tue, 28 Oct 2014 18:54:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45380) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjFf1-0002kh-4I for emacs-devel@gnu.org; Tue, 28 Oct 2014 18:54:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XjFes-0006en-Bx for emacs-devel@gnu.org; Tue, 28 Oct 2014 18:54:43 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:47359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjFes-0006e9-5C for emacs-devel@gnu.org; Tue, 28 Oct 2014 18:54:34 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XjFeq-00070b-F4 for emacs-devel@gnu.org; Tue, 28 Oct 2014 23:54:32 +0100 Original-Received: from 198.red-79-158-173.staticip.rima-tde.net ([79.158.173.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 28 Oct 2014 23:54:32 +0100 Original-Received: from ofv by 198.red-79-158-173.staticip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 28 Oct 2014 23:54:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 49 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 198.red-79-158-173.staticip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:arqObTpPzYPjGwn8Tdn9Du0XLCk= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:175947 Archived-At: Hello Alan, 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.". > > Is it going to be possible to express such ideas in our git world, in any > meaningful way? If so, how? Does git have a useable way of mapping its > cryptic revision identifiers to monotonically increasing natural numbers, > or some other useable scheme? > > I have bad feelings about this. Before switching to git mayself the lack of revision numbers was the strongest perceived inconvenience. Afterwards, it wasn't that bad. First of all, you need to realize the limitations of using revision numbers: they are meaningful only on the context of a branch. As soon as you have more than one branch and merge among them, revision numbers are an inconvenience. As you use Mercurial, which has revision numbers, the advice of the Mercurial experts possibly have some weight for you: http://mercurial.selenic.com/wiki/RevisionNumber Revision numbers referring to changesets are very likely to be different in another copy of a repository. Do not use them to talk about changesets with other people. Use the changeset ID instead. OTOH, there was some discussion on this list about using some tool-independent schema, using a combination of the author's e-mail and a timestamp.