Re: Git transition checklist

[Eric S. Raymond]

Glenn Morris <address@hidden>:
> Questions I would ask:
> How do I make a shared repository?

There isn't any such thing. But when you clone the repo you get all
the branches, and every time you pull (normally) all are updated, so
in a sense all repositories are automatically shared.

> How do I make a bound branch?

There is no such thing.  All branches require "git push" to publish the
changes to the upstream.

> What is the equivalent of bzr commit --fixes?

There isn't one.  If you want to associate a bug with a commit you'll
have to do it manually in the commit comment.

> Is there a changelog_merge equivalent?

Not directly in git as far as I know.  Various Emacs front ends
probably implement something like 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.
> 
> But not trivial to make them as useful as the bzr ones were.
> This is an issue right now with elpa, see separate emails.

Yes, looks like multimail will handle it.
 
> > 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.

Yes, indeed.

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

I don't know of a way to do it.

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

Noted. I'll use that as a model.

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

I can see the sense in that. I'll do it right away then.
 
> 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.)

I wrote the code, and I don't see anyone else taking responsibility for it.
Who else do you have in mind to do so?  I'm busy enough to *like* the
idea of handing it off.

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

I don't want to do these things in advance because the less time I
spend typing bzr commands the better.  Keeping track of the branch/repo
distinction and when I have to utter which kind of invocation makes
my head hurt.

I tried the bzr way shortly after that switch and...there's a *reason*
I went silent for several years.

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

Nobody's stopping you from working on that.

I did volunteer for the technical lead on this.  That doesn't mean you
can expect me to do work that would be more efficiently done by
others, nor that I will always exactly share your beliefs about what
is urgent when.

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

See above. I know nothing about hydra.  You should probably find someone
who does for that part.

> Makefile.in refers to a bzr file.

That I expect I can fix.  I've added it to my list.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>