From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: Converted git repository available for review Date: Fri, 21 Mar 2014 23:00:17 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: <20140322030017.GA29313@thyrsus.com> References: <20140321200042.236863805FB@snark.thyrsus.com> <532CE0B7.3010309@cs.ucla.edu> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1395457250 19377 80.91.229.3 (22 Mar 2014 03:00:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Mar 2014 03:00:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 22 04:01:00 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 1WRCBA-0001vq-9O for ged-emacs-devel@m.gmane.org; Sat, 22 Mar 2014 04:01:00 +0100 Original-Received: from localhost ([::1]:55521 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRCB9-0003F8-T0 for ged-emacs-devel@m.gmane.org; Fri, 21 Mar 2014 23:00:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRCB3-00033c-Jc for emacs-devel@gnu.org; Fri, 21 Mar 2014 23:00:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WRCAz-0006f2-4r for emacs-devel@gnu.org; Fri, 21 Mar 2014 23:00:53 -0400 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:58551 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRCAy-0006eq-VS for emacs-devel@gnu.org; Fri, 21 Mar 2014 23:00:49 -0400 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id CAD973805FB; Fri, 21 Mar 2014 23:00:17 -0400 (EDT) Content-Disposition: inline In-Reply-To: <532CE0B7.3010309@cs.ucla.edu> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 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:170756 Archived-At: Paul Eggert : > Thanks. I compared the latest revision (d245cfa) in the converted > git repository's master to the corresponding revision (116808) in > the bzr trunk, and found some discrepancies (see attached). They > fall into two major categories. > > 1. The git version is missing some changes to .gitignore files. > For example, we removed the arch-tag lines a while ago, but the git > version has resurrected them. I expect the conversion machinery > needs to be tweaked to handle .gitignore files correctly. Take a look at the relevant section of the lift script. What I've done is treat the Bazaar ignore files as authoritative for those revisions during which Bazaar was in use, ignoring .gitignores during that period. The other major possibility would be to simply remove .bzrignores where .gitignore files exist. I don't care. Either is doable; somebody make a policy choice, please? > 2. The git version has rewritten 100 ChangeLog lines, replacing > strings like "revno 108687" with strings like > "2012-06-22T21:17:42Z!eggert@cs.ucla.edu" using the principles you > discussed earlier. In many cases the ChangeLog lines have gotten > too long. I propose converting them to the new form and fixing > resulting line-length problems in the bzr trunk, now, so that the > automated conversion process has nothing to do in this area. I'll > volunteer to do this by hand, as it hardly seems worth automating. Here's I could do instead: select commit comments and ChangeLog revisions with overlong lines, mailboxize them, and craft some filter commands to fix up the line breaks. That would fix up the history for maximumm readability. But how much do we care about fewer than 108 overlong lines, really? I'm not even sure your small effort would be really justified, let alone my larger one. -- Eric S. Raymond