Re: Converted git repository available for review

[Paul Eggert <eggert@cs.ucla.edu>]

Eric S. Raymond wrote:

> 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.

There are no arch tags in the trunk now, in either .gitignore or 
.bzrignore files.  So something must have gone wrong in the lift.

> 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 bzr trunk has just one .bzrignore, at the root; it also has one 
.gitignore at the root and 12 other .gitignore files scattered all over 
the place.  (I don't know why.)  From what you say, the git review1 
should have the same pattern of files, with the old root .gitignore 
replaced by the translated .bzrignore (though I don't know why we should 
keep the .bzrignore -- shouldn't it be removed?).  However, the git 
review1 has 38 .gitignore files (counting the one at the root).  Where 
did they come from?

Plus, the git review1 is missing some .gitignore files that are in the 
trunk, namely lisp/cedet/.gitignore, lisp/leim/.gitignore, 
lisp/leim/quail/.gitignore.  Why is that happening?

Perhaps rather than delve into this too much, how about a different 
idea.  Currently people are using both bzr and git to access Emacs 
repositories, so they've tuned the .bzrignore and .gitignore files to 
match what they want from the different repository backends.  So why not 
leave these files alone?  When we switch from bzr+git to just git, we 
can remove the .bzrignore file.  This would be simpler than rewriting 
history, would be easier for everybody to understand, and would be less 
likely to go wrong.