From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: Git transition checklist Date: Wed, 8 Jan 2014 15:02:16 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20140108200216.GB5374@thyrsus.com> References: <20140108135200.8ECF9380834@snark.thyrsus.com> <1738kywelh.fsf@fencepost.gnu.org> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1389211397 27662 80.91.229.3 (8 Jan 2014 20:03:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Jan 2014 20:03:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: Glenn Morris Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 08 21:03:25 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W0zLY-00053W-JE for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 21:03:24 +0100 Original-Received: from localhost ([::1]:48726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0zLY-0002uJ-4C for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 15:03:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54497) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0zL2-0002K4-LN for emacs-devel@gnu.org; Wed, 08 Jan 2014 15:02:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0zKx-0005Zp-Iu for emacs-devel@gnu.org; Wed, 08 Jan 2014 15:02:52 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:60449 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0zKx-0005Zl-DD; Wed, 08 Jan 2014 15:02:47 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id CA3E3380E42; Wed, 8 Jan 2014 15:02:16 -0500 (EST) Content-Disposition: inline In-Reply-To: <1738kywelh.fsf@fencepost.gnu.org> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167802 Archived-At: Glenn Morris : > 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. -- Eric S. Raymond