Re: Bazaar references complicate the git transition

[David Reitter <david.reitter@gmail.com>]

Eric,

Thanks for working on the transition.

Please do not alter history in the git repository.  This would be bad for everyone downstream of the git mirror, and downright catastrophic for projects like mine (with 50+ merges of the course of years).

Why not use the mechanism that is foreseen for revising commit messages going forward?
Either "notes", as suggested, or a separate file (like the Changelog file).  If and when someone needs to resolve a reference, it could be easily done manually or automatically.

- David  (of aquamacs.org)


On Jan 11, 2014, at 10:54 AM, Eric S. Raymond <esr@thyrsus.com> wrote:

> This is particularly a heads-up for RMS and Andreas.
> 
> I missed something on my first pass through the git mirror that I
> shouldn't have.  Some commit comments have Bazaar local revision
> numbers in them referring to other commits.  (It is possible
> others have full hashes in them; I haven't looked closely enough at
> everything yet to be sure.)
> 
> Left uncorrected, this would be bad.  Those revision numbers 
> will become meaningless after the git transition. Information about
> which commits refer to which others would be lost.  This would be 
> particularly unfortunate with respect to reversion and correction
> commits.
> 
> The good news: in reposurgeon, I have a good tool for quickly finding
> and moving these to VCS-independent forms.  It's a VCS history editor
> which does just about everything you could imagine such a tool
> doing. It can take in RCS, CVS, Subversion, hg, bzr, and git
> repositories; it can emit all of those except CVS (Subversion output
> is alpha-stage).
> 
> The bad news: when reposurgeon edits a commit comment, all hashes of
> its descendants are (necessarily) altered.  This means, in practice, 
> that the reqired modifications cannot be done in situ on the 
> Savannah repo.
> 
> Here's how the procedure will need to go:
> 
> 1. Commits to bzr and git repos are temporarily closed.
> 
> 2. I clone the Savannah git repo.
> 
> 3. I signal for a reset of the Savannah git repo to empty.
> 
> 4. I apply a pre-built reposurgeon script fixing the references.
> 
> 5. I push the altered repo to the empty repo on Savannah.
> 
> 6. Commits are opened again.  (The commit-mirroring from bzr
>   will not care that the git repo has been altered.)
> 
> Step 4 will only take a few minutes (I'll build the modification
> script ahead of time).  The problem that is the steps around that
> require going through Savannah's admins, who (a) don't have procedures
> for this sort of thing, and (b) are often difficult to reach and get a
> response from.
> 
> That's why I think this needs an RMS intervention.
> 
> The two pain points are: (a) blocking/unblocking repo access, and
> (b) resetting the repo to empty. We need a way to push those buttons,
> either through a web interface or through an admin paying attention.
> 
> In the ideal case, Andreas and I would pick a date and time, then
> at that time join an IRC chat with a Savannah admin who has been 
> pre-briefed and knows what to do. The whole process should not take
> more than 30 minutes.
> 
> Note: this needs to happen *before* the release tags are cryptosigned,
> beacause of the hash invalidations.
> -- 
> 		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> 
> As the Founding Fathers knew well, a government that does not trust its honest,
> law-abiding, taxpaying citizens with the means of self-defense is not itself
> worthy of trust. Laws disarming honest citizens proclaim that the government
> is the master, not the servant, of the people.
>        -- Jeff Snyder
>