Re: Git transition checklist

[Stefan Monnier]

> 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.

>> 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.

> 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.

There's plenty of time to address this before the 24.4 release and hence
before the switch over.

> 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.


        Stefan