From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Git transition checklist Date: Thu, 09 Jan 2014 21:03:20 +0200 Message-ID: <83txddc70n.fsf@gnu.org> References: <20140108135200.8ECF9380834@snark.thyrsus.com> <1738kywelh.fsf@fencepost.gnu.org> <20140108200216.GB5374@thyrsus.com> <6pr48h52eq.fsf@fencepost.gnu.org> <87y52pg4ov.fsf@uwakimon.sk.tsukuba.ac.jp> <838uupeitt.fsf@gnu.org> <87sisxfu6q.fsf@uwakimon.sk.tsukuba.ac.jp> <87txddmmcj.fsf@igel.home> <87lhypfcs4.fsf@uwakimon.sk.tsukuba.ac.jp> <831u0hdrcp.fsf@gnu.org> <87fvoxf0x6.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1389294237 21213 80.91.229.3 (9 Jan 2014 19:03:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 19:03:57 +0000 (UTC) Cc: esr@thyrsus.com, schwab@linux-m68k.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 09 20:04:02 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 1W1Ktb-0002yh-Tz for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 20:04:00 +0100 Original-Received: from localhost ([::1]:53677 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1Ktb-0003aP-Fw for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 14:03:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1Kt7-0002yF-Q8 for emacs-devel@gnu.org; Thu, 09 Jan 2014 14:03:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1Kt3-00038k-4n for emacs-devel@gnu.org; Thu, 09 Jan 2014 14:03:29 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:42305) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1Kt2-000387-ST for emacs-devel@gnu.org; Thu, 09 Jan 2014 14:03:25 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MZ500E00E39OW00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Thu, 09 Jan 2014 21:03:23 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZ500ESSE9MOM10@a-mtaout22.012.net.il>; Thu, 09 Jan 2014 21:03:23 +0200 (IST) In-reply-to: <87fvoxf0x6.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:167963 Archived-At: > From: "Stephen J. Turnbull" > Cc: esr@thyrsus.com, > schwab@linux-m68k.org, > emacs-devel@gnu.org > Date: Fri, 10 Jan 2014 03:46:45 +0900 > > > jobs to be covered are, I think, (a) updating each branch from > > upstream and (b) merging and/or cherry-picking commits between the two > > branches each one of which is in a separate repository. TIA. > > No, both branches must be in the same repository to perform those > operations. I somehow understood that if one does "git remote add" to track the other repository, one can then fetch from there and merge or cherry-pick from the fetched commits. Is that wrong? > What this implies for Emacs release workflows I can't say because I > don't know how the Emacs release workflow works, specifically who > commits the merges and cherry-picks. Merges from the release branch to the trunk can be currently done by anyone with write access. The only requirement is to follow the protocol encoded in admin/bzrmerge.el, which in a nutshell merges all the revisions from the last merge point "till now", and then selectively reverts the changes we don't want on the trunk (e.g., because a different fix for the same problem was committed to the trunk). > The issue about multiple repositories is about whether a single > developer's feature branches should share an object database (at least > that's what I've been talking about, and I believe Andreas too). The > conclusion is that they shouldn't, but this will result in a certain > number of objects duplicated in several local repos. However, > reducing that duplication by --share'ing is not worth the risk of gc > in the origin repo corrupting the feature branches (because the origin > repo doesn't know about those branches). Feature branches worry me much less than the need to work with at least two (in the future maybe more) public and long-living branches: the development trunk and the release branch. As previously explained, frequent merging between them is a matter of routine, and since they diverge very quickly after the branching, having them colocated in the same directory will be a nuisance, because the build after switching to another branch will be annoyingly long, generally a full configure+bootstrap will be required.