From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Glenn Morris Newsgroups: gmane.emacs.devel Subject: Re: Git transition checklist Date: Wed, 08 Jan 2014 12:47:06 -0500 Message-ID: <1738kywelh.fsf@fencepost.gnu.org> References: <20140108135200.8ECF9380834@snark.thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1389203226 20643 80.91.229.3 (8 Jan 2014 17:47:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Jan 2014 17:47:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: esr@thyrsus.com (Eric S. Raymond) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 08 18:47:14 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 1W0xDk-0008IY-H9 for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 18:47:12 +0100 Original-Received: from localhost ([::1]:48138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0xDk-00015O-5S for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 12:47:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0xDg-000154-QW for emacs-devel@gnu.org; Wed, 08 Jan 2014 12:47:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0xDf-0005uh-7s for emacs-devel@gnu.org; Wed, 08 Jan 2014 12:47:08 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42070) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0xDf-0005ud-5C for emacs-devel@gnu.org; Wed, 08 Jan 2014 12:47:07 -0500 Original-Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1W0xDe-0005TZ-D1; Wed, 08 Jan 2014 12:47:06 -0500 X-Spook: Uzi Cocaine South Africa Serbian CIA Telex Freeh MDA X-Ran: aR%C/Q),m+RAsh+_0N;t@]PaQRTp%.Yz!|=c;&+*S`OP,bLN)f?"lEmS+Id.YVNQQ{cJ&H X-Hue: red X-Attribution: GM In-Reply-To: <20140108135200.8ECF9380834@snark.thyrsus.com> (Eric S. Raymond's message of "Wed, 8 Jan 2014 08:52:00 -0500 (EST)") User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:167761 Archived-At: 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.