Re: git status update?

[Kristian Høgsberg <krh redhat com>]

On Tue, 2009-03-03 at 10:30 -0500, Owen Taylor wrote:
> On Fri, 2009-02-27 at 05:20 +0100, Vincent Untz wrote:
> > Le jeudi 26 février 2009, à 14:22 -0500, Kristian Høgsberg a écrit :
> > > I think we're all set to press the big button after the release goes
> > > out, and in the meantime we can move over individual repos not part the
> > > GNOME release over if people want. Is there anything specific you want
> > > an update on?
> > 
> > I chatted briefly with Owen a few hours ago. I was thinking there'd be
> > a status update sent on the list while he was thinking that I was
> > looking at http://live.gnome.org/GitMigration. Small misunderstanding :-)
> > 
> > So let me take the wiki page and based on this, let's try to see what's
> > not ready. I'm assuming we don't need anything that's not mentioned on
> > the wiki page, which might or might not be true -- we'll have to check
> > this with the whole community before committing to a date for a
> > migration.
> > 
> >  + data integrity: what was verified? Reading the threads here, I got
> >    the feeling that a few modules were checked, and then some
> >    maintainers checked their modules. But are we 100% confident
> >    everything is fine?
> >    [blocker]
> 
> I'll see if I can get krh to summarize the situation here. One thing
> that he pointed out is that it isn't a disaster if some problem shows up
> later - we aren't throwing away the svn and cvs data - but certainly the
> less we need to go back up and fix later the better.

I wrote a verification script a while ago that I never committed.  It
compares the files in a branch or tag against from svn to the same
branch or tag in git.  When I got this script running it revealed a
bunch of issues with the svn->git import and with the original cvs->svn
import.  I put the verification effort on the back burner and started
fixing the importer.

It looks like the importer is in pretty good shape and I just dusted off
and committed the verifier tool to the gnome-git-migration repo.  I'm
redoing the mass import now and will try running the verifier over the
repos again.  A successful run of the verifier will establish that the
contents of every branch (including master) and tag are identical
between svn and git versions of a repo.  Olav also suggested comparing
blame output - this is doable, we have the svn revision numbers in the
git commit messages so it is possible to map git blame output to
something that resembles svn blame output - I'm not sure this is
worthwhile though?

And as Owen says, it's not a hit-and-run import - we'll be around after
the bulk of the work is done to help out with whatever issues come up
after the conversion.  We can redo any import and replay any post-import
git history onto the a re-imported repo.  There's not going to be any
data loss.

I'll send an update when the new import has finished and I've run the
verifier.  I already know that there are issues with some of the CVS
tags.  The cvs->git importer combines cvs per-file commits into git
commits based on commit message and timestamps, but some of the cvs tags
have raced with a concurrent commit and thus have tagged files from
different cvs commits.  The git tag points to one of the two cvs commits
and this differs from the cvs tag.  I don't consider this a big problem,
the damage is historical and the release tarball probably went out with
contents that didn't match the tag (unless the maintainer explicitly did
make dist from a fresh checkout of the tag).

> >    (I would still think that it'd be nice to have a very limited script
> >     that can only do checkout/update/commit for translators, so they
> >     don't have to struggle with the git ui, but well, that's just my
> >     opinion)
> >    [not blocker, unless l10n.gnome.org gets broken]
> 
> Alternate command line frontends just seem confusing to me. Improvement
> here to me is getting translators away from the command line, whether
> it's commits from l10n.gnome.org, transfix, pootle, or whatever.

I tried to write one and it just drove home the point that it's not
worth it.  It's better to just provide a svn -> git cheatsheet for the
typical translator workflow.  When things work ok, the script isn't
really improving much over the git command line, when things go wrong,
it's another layer to add to the confusion.  The two actions in the
translator workflow where git is different enough from svn to possibly
justify a wrapper are

        1) Provide commit+push in one command.  Just a small convenience
        if you're not used to the distributed work flow where commit
        doesn't push to the server and might forget to push.
        
        2) git pull won't pull down new commits if you have uncommitted
        changes in your working copy.  The wrapper script could patch
        out the local changes, run git pull, then patch the changes back
        in.

But in both cases I think it's better to just get used to the slightly
different workflow: 1) remember to push and 2) finish and commit your
changes before pulling.

cheers,
Kristian