From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Git transition checklist Date: Fri, 10 Jan 2014 03:46:45 +0900 Message-ID: <87fvoxf0x6.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1389293230 8637 80.91.229.3 (9 Jan 2014 18:47:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 18:47:10 +0000 (UTC) Cc: esr@thyrsus.com, schwab@linux-m68k.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 09 19:47:16 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 1W1KdP-0008J3-K0 for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 19:47:15 +0100 Original-Received: from localhost ([::1]:53613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1KdP-0000M9-0W for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 13:47:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1KdE-0000Lm-KT for emacs-devel@gnu.org; Thu, 09 Jan 2014 13:47:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1Kd7-0006ct-Ac for emacs-devel@gnu.org; Thu, 09 Jan 2014 13:47:04 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:51943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1Kcy-0006bq-1Y; Thu, 09 Jan 2014 13:46:48 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7177E970972; Fri, 10 Jan 2014 03:46:45 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 674FE1A2E82; Fri, 10 Jan 2014 03:46:45 +0900 (JST) In-Reply-To: <831u0hdrcp.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:167962 Archived-At: Eli Zaretskii writes: > I guess we have a consensus, then. I think Stefan also suggested > separate repositories. > So would someone "in the know" please update the Wiki with the > instructions how to set this up and what the workflow would look like > for working on the trunk and a release branch in this way? The main > 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. The only thing git can do between repositories is fetch objects that are reachable from a reference. Merging branches requires that both be present in one repository; the resulting DAG structure can then be fetched and merged into other repositories. Similarly with cherry-picking. 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. 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). > Btw, I think git can use something called "alternates" instead of hard > links? Is this relevant? Yes, that's precisely what --shared does. > > > Copying commits between clones is straight forward with git fetch. > > > > True but I doubt Glenn and Eli are worried about that. > > ??? Merges and cherry-picks between the release branch and the trunk > happen all the time, as long as the release branch is active. Sure, but you won't be using git fetch directly to do that. You'll use git pull or git push, which do any necessary fetching implicitly. What Andreas is talking about is reorganizing the object databases in a way that won't affect the branch structure visible in the origin or in the clone. (At least, that's what I think he's talking about.)