Re: New review conversion of Emacs repository

[Eric S. Raymond]

Paul Eggert <address@hidden>:
> I looked at the conversion and have some questions.  Sorry, it's
> been so long since I reviewed the last conversion that I forgot
> whether these issues have come up before.  (If they have, please
> just consider this as stuff that still worries me mildly. :-)

These issues have not come up before.
 
> * On the master/trunk branch, the git repository contains 549
> commits more than the bzr repository does, 117867 versus 117318.  I
> assume this is because the git repository lists each merged change
> separately rather than a single 'Merge from' commit.  I wanted to
> confirm this, though. For example, git commit
> 94075d6f559ced1fab36c50bdfa51a612f422080 by Glenn Morris
> <address@hidden> dated Sep 7 22:57:24 2014 -0700 isn't explictly
> mentioned in the bzr log, and was this because it was part of the
> bzr merge that produced trunk bzr 117839 dated 2014-09-07 23:00:58
> -0700 by Glenn?  Are there any other reasons a commit should appear
> in one log but not the other?

I can't think of any other reason that the commit count on the git
side would be *greater*. Because of changeset coalescence in the CVS 
part of the history one would actually expect the commit count to drop.

In genersl bzr commits should go to git commits 1-1.

> * Rewriting revision numbers occasionally makes ChangeLog lines
> longer than 80 characters.  I propose that we fix this via a manual
> pass after the change, something that's done fairly routinely for
> ChangeLog files anyway.

Yes, I was planning to do this.

> * This conversion treats ChangeLog as metadata, and I'd feel more
> comfortable if ChangeLog files were treated as data.  For example,
> if I ask the git repository "Please give me src/ChangeLog as the end
> of 2012", I git a different answer than if I ask the bzr repository
> the same question.  (See the diff output below.)  I'd feel more
> comfortable if these changes were applied to the ChangeLog files via
> the abovementioned pass after the conversion, as that way the old
> git data will match the old bzr data exactly.

It's within the capability of my tools to do it either way.  The question
of how it should be done is really one about the philosophy of the conversion.
I see two possible positions:

Navigability first: Translate ChangeLog references so that after
the switchover they can all become (in effect) hotlinks, no matter
where they are in the history.

Reproducibility first: Don't translate, so old revisions have the same
ChangeLog comment they did formerly, but the commit references in them
can't in general be made to work as hotlinks.  (No, an index of bzr
revisions wouldn't be good enough to enable this; there are too many
strange mutant reference forms in there.  And CVS references.  And
plain old typos.)

I have so far chosen to put navigability first, because I think that
(1) one central purpose of the conversion is to make the modification
history of the code as easy as possible to explore, and (2) I don't
expect the old repository to entirely vanish; it will still be around as
an archive for those who value bit-for-bit fidelity of the old ChangeLogs.

There is, of course, a case for going in the opposite direction as you
suggest.  It's a policy rather than technical decision, so I would
prefer to get some sense of what the whole dev group wants rather than
either you or me deciding on our own hook. In the absence of a strong
consensus on the matter I guess it would be up to Stefan to decide.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>