Re: Git transition checklist

[Eric S. Raymond]

Stefan Monnier <address@hidden>:
> > That's easy.  Make a patch sequence from your bzr branch using sendto
> > - the format is compatible with GNU patch.  git checkout the branch
> > name at the equivalent point in the git repo.  Use GNU patch to apply.
> > Fill in change comments as required.
> 
> Sounds like a lot of manual work and it doesn't seem to preserve history
> (e.g. merges that might have taken place).  For a branch with a couple
> commits that's probably OK, but with my 5 year-old branch it's
> a non-starter, unless I misunderstand something.

I don't know what to tell you. *I* may misunderstand; I don't know bzr
well enough to suggest an alternative or write a procedure, and on top
of everything else I need to do it is highly unlikely that I will be
able to learn bzr well enough to change that.

If branch transplant is to be to be automated, I think it's going
to fall on you or Eli to do it.

> >> 7. What about the mail messages to emacs-diffs mailing list?  That
> >> should be working as well, and support pushes to non-trunk
> >> branches.
> > That is trivial in git.  Andreas can set it up in minutes.  I could too,
> > but I don't have write access to the repo hook files.
> 
> Savannah has support for Git commit mails (we use them for the `elpa'
> branch), but they kind of suck:
> - it's "one mail per push" instead of "one mail per commit"
>   (I can live with that, but it has annoying consequences).
> - the email's "Subject:" is useless (part of the problem is that
>   since there are several commits in it, you can't just take the first
>   line of *the* commit message, since there are several commit messages).
> See http://git.savannah.gnu.org/r/emacs/elpa.git/config for the config
> we currently use.

So from the point of view of our transition this is a solved problem
(enail notifications won't be interrupted) but there's a separate
issue with that Savannah hooks needing some work.  OK, so noted.
 
> > Stefan Monnier added these:
> >
> > - Improve vc-git.el so that it can automatically enable smerge-mode when
> >   opening a conflicted file and (probably conditional on a config var)
> >   mark the file as "not conflicted any more" when saving with no
> >   remaining diff3 markers.
> >   This currently works in vc-bzr.el (and vc-svn.el as well, IIRC).
> >
> > - Improve vc-git.el with vc-git-conflicted-files so that
> >   vc-find-conflicted-files works for Git as well.
> >
> > Thierry Volpiatto pointed out that these issues are addressed now:
> 
> No, they're not.
> 
> > Better cross-VCS integration of smerge mode would be nice but is not a
> > git-vs-bzr issue
> 
> It is.  I want my workflow to work about as well as before.  I can live
> with the lack of true lightweight checkouts, but manual conflict
> resolution is something I do every day, so it needs to work well.

I'm going to need a very detailed soecification of what you want, then.
You can't assume I know what the bzr behvior looks like, either.

> > 0. Before changeover, we prepare a shellscript that creates annotated
> >    cryptosigned tags for the historical versions. (This will require
> >    Stefan to create an "Emacs maintainer" GPG identity if none exists.)
> [...]
> > 6. Stefan applies the script to make cryptosigned historical release tags.
> 
> I'd rather delegate those.

I could do this - that is, create a maintainer identity and do all the
cryptosigning.  Then I could hand you the private key.  You'd have to
trust me not to keep a copy and use it for nefarious ends. :-)
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>