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: Sat, 22 Mar 2014 00:29:21 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: <20140322042921.GA29817@thyrsus.com> References: <20140321200042.236863805FB@snark.thyrsus.com> <532CE0B7.3010309@cs.ucla.edu> <20140322030017.GA29313@thyrsus.com> <532D057D.9050305@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 1395462594 31284 80.91.229.3 (22 Mar 2014 04:29:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Mar 2014 04:29:54 +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 05:30:05 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 1WRDZM-0000Nm-84 for ged-emacs-devel@m.gmane.org; Sat, 22 Mar 2014 05:30:04 +0100 Original-Received: from localhost ([::1]:55668 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRDZL-0008AJ-Rv for ged-emacs-devel@m.gmane.org; Sat, 22 Mar 2014 00:30:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRDZE-00082x-VN for emacs-devel@gnu.org; Sat, 22 Mar 2014 00:30:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WRDZA-0001VB-KR for emacs-devel@gnu.org; Sat, 22 Mar 2014 00:29:56 -0400 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:58933 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRDZA-0001V5-F0 for emacs-devel@gnu.org; Sat, 22 Mar 2014 00:29:52 -0400 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id B31CB3805FB; Sat, 22 Mar 2014 00:29:21 -0400 (EDT) Content-Disposition: inline In-Reply-To: <532D057D.9050305@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:170760 Archived-At: Paul Eggert : > Eric S. Raymond wrote: > >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. > > Sorry, I'm not really following all that, as I haven't read the lift > script. Still, it puzzles me that the result is a .gitignore that > has the wrong data in it, in the sense that it has an arch tag, > something that is clearly wrong since we went through and removed > those. If we're generating .gitignore files from .bzrignore files, > and if the .bzrignore file just before the bzr-to-git transition > lacks an arch tag, why would the .gitignore file after the > transition have it? And if we're using some other process to > generate the .gitignore file, then how did it manage to keep the > arch tags even though we removed them? I don't know. Maybe we can figure it out together. Let me explain in detail what is currently happening and why. First, why: the conversion goal is to make the entire history convenient for git browsing - that is, as though git had neen in use all along. For our purposes, the history has two sections: pre-bzr and post-bzr. In the pre-bzr section it is pretty clear what to do, because .cvsignore files are upward-compatible to .gitignores. So we just rename them. Policy for the post-bzr-changeover section is a little trickier. There are three kinds of relevant files in that section; leftover .cvsignores (presumably never modified afther the switch to bzr), .bzrignore files, and .gitignore files. Simply discarding the .cvsignore revisions after that point makes sense. The information in them is stale. Neither bzr nor git uses them. They're just clutter. It's also clear enough what to do when a revision has .bzrignres but no .gitignores - syntax-translate the .bzrignores (which is trivial) and rename them. The issue is what to do when a revision has both .bzrignores and .gitignores. The pfresent policy is to treat each .bzrignore with a matching.gitignore as authoritative; that is, the .bzrignore is translated and overwites the .gitignore. The arch tag you're seeing must have been removed in .gitigores but not in .bzrignores. Other than the (trivial) bar-to-git syntax change I'm not messing with the data or trying to do anything clever. # # IGNORE FILES # # Remove every .cvsignore not older than when .gitignores were # first added. Then rename all remaining (older) .cvsignores to # corresponding .gitignore paths; the syntax is upward-compatible. # The date marks the introduction of .gitignore files. # <2009-02-03T23:32:38Z>..$ expunge /\.cvsignore$/ path (.*)/\.cvsignore$ rename \1/.gitignore # # Then treat .bzrignore files as authoritative, after changing leading # "./" to "/". (The only other syntax incompatibility is "RE:", which # the Emacs repository never uses.) The date marks the introduction of # .bzrignore files. # <2009-12-27T21:38:14Z>..$ expunge /\.gitignore$/ =B & [/\.bzrignore$/] filter --regex :^\./:/: path (.*)/\.bzrignore$ rename \1/.gitignore > How about if we fix the .bzrignore and .gitignore files to agree > now, by hand, so that this part of the bzr-to-git transition is a > no-op? That might make sense after 24.4 -- Eric S. Raymond