Re: Converted git repository available for review

[Eric S. Raymond]

Paul Eggert <address@hidden>:
> 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
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>