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 21:12:29 -0500 Message-ID: <6pr48h52eq.fsf@fencepost.gnu.org> References: <20140108135200.8ECF9380834@snark.thyrsus.com> <1738kywelh.fsf@fencepost.gnu.org> <20140108200216.GB5374@thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1389233554 14460 80.91.229.3 (9 Jan 2014 02:12:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 02:12:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: esr@thyrsus.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 09 03:12:42 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 1W156v-0005Wl-Sa for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 03:12:42 +0100 Original-Received: from localhost ([::1]:49789 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W156v-0002NX-0T for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 21:12:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W156o-0002NR-UY for emacs-devel@gnu.org; Wed, 08 Jan 2014 21:12:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W156k-00056j-5Q for emacs-devel@gnu.org; Wed, 08 Jan 2014 21:12:34 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W156k-00056f-20 for emacs-devel@gnu.org; Wed, 08 Jan 2014 21:12:30 -0500 Original-Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1W156j-0002gU-Ax; Wed, 08 Jan 2014 21:12:29 -0500 X-Spook: INS Legion of Doom fraud Nazi CISU Zachawi CipherTAC-2000 X-Ran: ^WMZ:~,RGz4~U'!#?GB5udV__?eBFGF&$QN#{G~QbR/c>zUIM~aAh1nGRzn7jq4x7]yWfK X-Hue: white X-Attribution: GM In-Reply-To: <20140108200216.GB5374@thyrsus.com> (Eric S. Raymond's message of "Wed, 8 Jan 2014 15:02:16 -0500") 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:167846 Archived-At: "Eric S. Raymond" wrote: >> 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. Let me explain a bit more: What I have now is an emacs-bzr/ directory, which is a shared repository. Within that directory I have multiple trunk/ directories, also directories for emacs-24, emacs-23 (etc) branches. These are all independent. The .bzr directory within each branch directory is very small, only the top-level .bzr directory is not. I can simply copy trunk/ to trunk-test/ at any time using standard Unix tools to have a new directory that tracks the upstream repository independently of trunk/, and does not waste space with a duplicate copy of a large .bzr directory. If I fetch new revisions from upstream in trunk/, those are available locally when I want to update trunk-test/, and do not have to be refetched from the remote server. Can I replicate such a setup? >> How do I make a bound branch? > > There is no such thing. [...] > >> What is the equivalent of bzr commit --fixes? > > There isn't one. [...] > >> Is there a changelog_merge equivalent? > > Not directly in git as far as I know. [...] I'm sure I will "enjoy the greater simplicity that results from the absence of many" VCS features I've been using. > Yes, looks like multimail will handle it. AFAIK, no-one has actually tested this to see if the output fixes the issues. Also Ted suggested an alternative. Someone should see which is best. > I wrote the code, and I don't see anyone else taking responsibility for it. The people who've been fixing it and developing it over the past decade have been taking responsibility for it. You'll find their names in the ChangeLog. > Who else do you have in mind to do so? I'm busy enough to *like* the > idea of handing it off. Good ol' Maintainer: FSF sounds right. It's only vc-dispatcher.el you'll have to change. (Though Andre Spiegel has been AWOL for many years too.) > Nobody's stopping you from working on that. I did not ask for this change of VCS, and don't expect to benefit from it. > See above. I know nothing about hydra. You should probably find someone > who does for that part. I know about it, but I am not going to work on a VCS switch, since I prefer to work on the 24.4 release. http://lists.gnu.org/archive/html/hydra-users/ Probably all that needs to be done is to email the hydra-users list and ask them to switch the emacs input from bzr to git at the right time. http://hydra.nixos.org/jobset/gnu/emacs-trunk#tabs-configuration