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: Referring to revisions in the git future. Date: Thu, 30 Oct 2014 12:32:55 +0900 Message-ID: <87tx2m2pw8.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20141028223312.GB6630@acm.acm> <20141029004942.GA25241@thyrsus.com> <20141029105202.249acb5a@anarchist.wooz.org> <87bnouapiy.fsf@fencepost.gnu.org> <20141029150600.GA5701@thyrsus.com> <20141029141216.7abbbc0d@anarchist.wooz.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1414640005 18620 80.91.229.3 (30 Oct 2014 03:33:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Oct 2014 03:33:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Barry Warsaw Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 30 04:33:18 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 1XjgU9-0006RG-Iz for ged-emacs-devel@m.gmane.org; Thu, 30 Oct 2014 04:33:17 +0100 Original-Received: from localhost ([::1]:50696 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjgU8-0002ct-Vn for ged-emacs-devel@m.gmane.org; Wed, 29 Oct 2014 23:33:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50700) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjgTz-0002cS-8m for emacs-devel@gnu.org; Wed, 29 Oct 2014 23:33:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XjgTr-0005a5-Cn for emacs-devel@gnu.org; Wed, 29 Oct 2014 23:33:06 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:36113) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjgTr-0005a0-2m for emacs-devel@gnu.org; Wed, 29 Oct 2014 23:32:59 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 12DBD1C3B0E; Thu, 30 Oct 2014 12:32:56 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 069A91A27CF; Thu, 30 Oct 2014 12:32:55 +0900 (JST) In-Reply-To: <20141029141216.7abbbc0d@anarchist.wooz.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:176050 Archived-At: Barry Warsaw writes: > Sure, but [changing revision numbers is] rare and only happens with > some funky (and I'd argue incorrect directionally) merges. Actually, it happens in *every* merge -- the local revnos are obsoleted and turn into something meaningless in many cases (you get the base, but who cares about that? -- it's whether the commit being compared to is before or after the *merge* that matters). And even on the bzr list you'd occasionally see the "it's in my commit r666042" "no, it's not, and that's not even your commit" "oops, push push must push, try now" conversation. Or worse "sorry, that's in the review pipeline, wait for it" :-) conversation, but that was project-specific. True, it only happens in the public repo if people merge public into local and then push, and you can configure the public repo to refuse such pushes (at least you can in bzr and hg, I'm not sure if git supports this well even today). But seriously, I'm frequently far enough out of sync (say, 5 to 10 commits :-) that the revnos are just as useless as SHA1s would be. The overhead of pulling just to get the commit under discussion swamps any difference in convenience as far as I'm concerned. YMMV, of course, that's just me. > And besides, those sequential numbers are only for our convenience, > right? ;) Sure, and they're convenient mostly because you're used to them. They really don't have more content than SHA1s do, but they're easier to read because they're decimal and relatively small. I'm not going to deny that, but I think everybody would be better off if some infrastructure were created to make SHA1s easier to manipulate. For example, in response to my earlier post, Stefan responded that SHA1s aren't that easy to recognize and you'll get too many false positives. My initial rebuttal was "Eh?!", but a more constructive response is, so we establish a convention of prefixing with "sha:" or "SHA:". The issue of "which repo" (especially for ELPA) is real, too, but again context is likely to give you a very good first guess, and after that you can configure some kind of variable to improve Emacs's guessing. This ain't rocket science, and it's the kind of thing Emacsen are *very* good at.