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: Thu, 09 Jan 2014 13:27:44 +0900 Message-ID: <87y52pg4ov.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1389241747 27357 80.91.229.3 (9 Jan 2014 04:29:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 04:29:07 +0000 (UTC) Cc: esr@thyrsus.com, emacs-devel@gnu.org To: Glenn Morris Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 09 05:29:13 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 1W17F1-0007o7-3w for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 05:29:11 +0100 Original-Received: from localhost ([::1]:50052 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W17F0-0001Cd-Fk for ged-emacs-devel@m.gmane.org; Wed, 08 Jan 2014 23:29:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W17Eq-0001CT-RP for emacs-devel@gnu.org; Wed, 08 Jan 2014 23:29:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W17Ej-00089x-HB for emacs-devel@gnu.org; Wed, 08 Jan 2014 23:29:00 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:43893) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W17Ei-0007wf-Vg; Wed, 08 Jan 2014 23:28:53 -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 C90749708E0; Thu, 9 Jan 2014 13:27:44 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id BD5951A2E82; Thu, 9 Jan 2014 13:27:44 +0900 (JST) In-Reply-To: <6pr48h52eq.fsf@fencepost.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:167852 Archived-At: Glenn Morris writes: > Can I replicate such a [bzr shared repo] setup? > How do I make a bound branch? Replicate, no -- there are minor semantic differences. Get space savings and avoid network traffic when the object is available locally, yes. Bound branch, see Option 2 below. DO NOT read the footnotes unless you are a git fan, if you're a bzr kinda hacker your brain will explode. Two ways to do it. Both start by cloning the upstream repo cd $PARENT_DIRECTORY_FOR_EMACS_REPOS git clone $URL_TO_SAVANNAH_GIT_EMACS_TRUNK trunk Option 1: # In same CWD as above: git clone --shared trunk ws1 Option 2: # In same CWD as above; [branch2] is an optional argument to # choose the named branch from trunk to check out. It may be # irrelevant to the Emacs repo setup, I don't know. # The git-new-workdir script is in the git contrib directory, it's # not enabled by default. git new-workdir trunk ws2 [branch2] CAVEAT for both options: DO NOT BLOW AWAY TRUNK!! It is the equivalent of the shared-repo's .bzr. Difference between the options: Option 1 is like a regular bzr branch: branch1's history is identical to trunk up to the point of cloning, after that independent of trunk. It is possible to switch the workspace to a different branch using git-checkout, but that branch's history may not be complete unless you pull it again from trunk.[1] Option 2 has many similarities to a *local* bound branch. *All* history and branch configuration is shared.[2] This has some glitches. The obvious one is that it only works locally, so unlike a bzr bound branch it's useless as an "automatically synced staging area for pushes." Almost as obvious, since HEAD is usually a pointer to a branch ref (not to a commit), a commit in ws1 will advance HEAD in all workspaces that have checked out the same branch. This is usually not what is wanted in a development workspace. For more glitches, ask Stefan. It's against my religion to believe in glitches in git, so surely there aren't any more. Now, you can make an informed choice. Pick your poison! I hereby license this text to all under the MIT/X license. For a signed paper copy, send me an SASE (110 yen). Footnotes: [1] Technically the history DAG is complete because the objects directory is hardlinked in both GIT_DIRs, but the branch ref in ws1 does not advance with the branch ref of the same name in trunk. [2] Technically, the refs and .git/config as well as the DAG are shared.