Re: Git transition checklist

[Glenn Morris]

Eric S. Raymond wrote:

> The only omission is that I left out the git equivalent of bzr bundle.

Bundles are useless anyway IMO.

Questions I would ask:
How do I make a shared repository?
How do I make a bound branch?
What is the equivalent of bzr commit --fixes?
Is there a changelog_merge equivalent?

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

But not trivial to make them as useful as the bzr ones were.
This is an issue right now with elpa, see separate emails.

> Replacing the function emacs-bzr-get-version with this will rectify a
> design error; it callers knew the string "bzr", which they should not have -

Yes alright, fair enough. Though I think "emacs-vcs-version" or
"emacs-dev-version" is less of a mouthful. Ditto with INSTALL.BZR ->
INSTALL.DEV or somesuch.

> This code is simpler than emacs-bzr-get-version because "git describe" is
> very fast - there's no need to avoid calling it for better performance.

The current version deliberately avoids calling an external executable
during dumping of Emacs, because that seemed safer to me (one less point
of failure). I think a git version should do the same (but I expect to
hear it's impossible).

BTW, people have previously posted git versions, eg
http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00430.html

> The change to integrate this and fix its callers is easy, five minutes'
> work which I will cheerfully do immediately after the repo switchover.
> No need to do it before as it really only becomes crucial to have this
> working for the next point release.

Err, no. It is completely useless for releases. It is very useful for
the time inbetween releases, and will start being needed right away.

> Thierry Volpiatto pointed out that these issues are addressed now:
> "You can use git-mergetool with ediff-merge for this" he said, 
> and gave a recipe.

That is in no way a solution.

> as VC's maintainer,

I was not aware you were VC's maintainer, except perhaps of
vc-dispatcher.el. (A maintainer who does nothing for 5+ years is not a
maintainer IMO.)

> 10. I will do the work required to update /etc and /admin to reflect
>     git use over the following few days.

I don't see why these things cannot be done in advance, since there is
no rush for this switch.
Why, you could even publish your work on a bzr branch so others can
help...
Eg I would like admin/update_autogen to be working right away.

Other things:

Work with hydra-users mailing list to update hydra build config.
Again, this is something that should work right away.

Makefile.in refers to a bzr file.