[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Git transition checklist
From: |
Eric S. Raymond |
Subject: |
Re: Git transition checklist |
Date: |
Wed, 8 Jan 2014 15:02:16 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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>
- Re: Git transition checklist, (continued)
- Re: Git transition checklist, Stefan Monnier, 2014/01/08
- Re: Git transition checklist, Andreas Schwab, 2014/01/08
- Re: Git transition checklist, Glenn Morris, 2014/01/08
- Re: Git transition checklist, Stefan Monnier, 2014/01/08
- Re: Git transition checklist, Dani Moncayo, 2014/01/08
- Re: Git transition checklist, Bob Proulx, 2014/01/12
- Re: Git transition checklist, Bastien, 2014/01/13
Re: Git transition checklist, Bastien, 2014/01/08
Re: Git transition checklist, Glenn Morris, 2014/01/08
- Re: Git transition checklist,
Eric S. Raymond <=
- Re: Git transition checklist, Eli Zaretskii, 2014/01/08
- Re: Git transition checklist, Andreas Schwab, 2014/01/08
- Re: Git transition checklist, James Cloos, 2014/01/08
- Re: Git transition checklist, Rüdiger Sonderfeld, 2014/01/08
- Re: Git transition checklist, Eli Zaretskii, 2014/01/09
Re: Git transition checklist, James Cloos, 2014/01/08
Re: Git transition checklist, Rüdiger Sonderfeld, 2014/01/08
Re: Git transition checklist, Rüdiger Sonderfeld, 2014/01/08
Re: Git transition checklist, Eli Zaretskii, 2014/01/09
Re: Git transition checklist, Andreas Schwab, 2014/01/09