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: resolving ambiguity in action stamps Date: Sun, 14 Sep 2014 22:30:58 +0900 Message-ID: <87egve49d9.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87wq9841zx.fsf@uwakimon.sk.tsukuba.ac.jp> <20140913053525.GA15582@thyrsus.com> <87tx4c3t4k.fsf@uwakimon.sk.tsukuba.ac.jp> <20140913.092630.2301242291023129455.hanche@math.ntnu.no> <20140913105058.GA16776@thyrsus.com> <87r3ze4pw6.fsf@uwakimon.sk.tsukuba.ac.jp> <20140914105531.GA30576@thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1410701503 21444 80.91.229.3 (14 Sep 2014 13:31:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Sep 2014 13:31:43 +0000 (UTC) Cc: Harald Hanche-Olsen , emacs-devel@gnu.org To: esr@thyrsus.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 14 15:31:35 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 1XT9tu-0006uf-QP for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2014 15:31:35 +0200 Original-Received: from localhost ([::1]:54630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XT9tt-00032z-Sa for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2014 09:31:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XT9tb-00031s-3R for emacs-devel@gnu.org; Sun, 14 Sep 2014 09:31:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XT9tT-0004Hr-K0 for emacs-devel@gnu.org; Sun, 14 Sep 2014 09:31:15 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:50647) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XT9tT-0004HP-AL for emacs-devel@gnu.org; Sun, 14 Sep 2014 09:31:07 -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 A80EB1C3963; Sun, 14 Sep 2014 22:30:58 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 97FA41A28C8; Sun, 14 Sep 2014 22:30:58 +0900 (JST) In-Reply-To: <20140914105531.GA30576@thyrsus.com> 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:174287 Archived-At: Eric S. Raymond writes: > One is a genuinely funny gotcha. You can't get to git hashes > without going through something semantically like my version stamps > on the way! I disagree. "Think hard" (your words!) about the workflow: Find a bug and make it work Then just "git blame" will find the jerk! More seriously, it seems to me that in many cases the bug will be localized to a particular commit using bisect. In others, the *place* of the bug is known, and git blame will indeed give a pretty good idea of the commit whether you know *when* it was introduced or not. (Of course the bug patch may have been shadowed by a later change in the same place, but it's not clear to me how else one would get a revision id for an "old" bug found by place.) If the bug is recent enough -- ie, the only commit in the pull that broke your Emacs -- it's trivial to get the commit. If it's a bit older, I suspect grepping the log for file and function is more likely to catch the culprit than looking for random authors and dates you think are incompetent and unlucky respectively (or is it the other way around?) So isn't it the reverse: an April Fool's joke is the only time date!author is likely to find the commit faster? (Of course if you *have* the date as in the refs you advocate, git log --since/--until will narrow it down. But we're talking about how you figure out which commit needs a ref to put in the log at this point.) > The second problem is that it's not future-proof. Someday we might > have to change VCSes again; git is the *fifth*, after RCS CVS Arch > bzr. It would be unwise to assume that nobody will ever have a > better idea. I don't. But if the new one can't run $VCS filter-branch --commit-filter ... as fast as git, I'd have serious doubts about the sanity of the proponents. Even on a 200,000 commit repo, that's just not going to take a ton of time, and only needs to be done once. > At that time it would be a Really Good Thing if as few of our commit > refs as possible are opaque magic cookies Actually, I disagree. It would be a really good thing if they are precise. Do you really want to put anybody through the trouble of translating randomized format cookies, which may point to any of several commits, again? Then revising their scripts every time a new variant shows up? A 40-hexit SHA1 is unlikely to be written in any variant, except for case. (Well, I suppose we have a few 133t hack0rz around, and swapping 3s and Es would play havoc....) The "magic cookie" mapping should be a by-product of the conversion process (did I hear somebody say his git commits should be 1-1 with bzr commits?), and then "filter-branch --commit-filter" is your friend, if you have a database with the mapping lying around somewhere. > Thus, it seems best to me to just land on a VCS-independent and > human-readable version-stamp format and stay there, treating > VCS-specific commit-refs as a practice flaw to be avoided. Existence proof comes before characterization, please.