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: Rewriting bzrmerge.el Date: Mon, 24 Nov 2014 00:11:12 +0900 Message-ID: <87k32mrlyn.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20141027000718.F09B5382A66@snark.thyrsus.com> <87bno8y0rt.fsf_-_@engster.org> <871tp4xx4i.fsf@engster.org> <87tx20whtq.fsf@engster.org> <87lhn4rx0v.fsf@engster.org> <838uj3tztm.fsf@gnu.org> <87egsvrz6e.fsf@engster.org> <83mw7jrxt9.fsf@gnu.org> <87a93jrw83.fsf@engster.org> <83ioi7rn9o.fsf@gnu.org> <87oarysr3u.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1416755508 27522 80.91.229.3 (23 Nov 2014 15:11:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Nov 2014 15:11:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Magne Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 23 16:11:41 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 1XsYp9-00084s-HE for ged-emacs-devel@m.gmane.org; Sun, 23 Nov 2014 16:11:39 +0100 Original-Received: from localhost ([::1]:48913 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsYp9-0006cR-2S for ged-emacs-devel@m.gmane.org; Sun, 23 Nov 2014 10:11:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsYoy-0006c8-Ly for emacs-devel@gnu.org; Sun, 23 Nov 2014 10:11:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsYor-0003rv-5m for emacs-devel@gnu.org; Sun, 23 Nov 2014 10:11:28 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:49804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsYoq-0003mZ-Sk for emacs-devel@gnu.org; Sun, 23 Nov 2014 10:11:21 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 1252F1C395D; Mon, 24 Nov 2014 00:11:13 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id DF83E1A2892; Mon, 24 Nov 2014 00:11:12 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:178074 Archived-At: Lars Magne Ingebrigtsen writes: > If there is a way to get two separate branches checked out at the same > time without doubling the disk spaces used, that would be nice. How much more than "negligible" is unacceptable, and how long before you cross that line is acceptable? You see, git is not bzr or hg (yes, I know about bzr shared repos, but my bzr setup with about 5 Emacs branches including trunk, emacs-24, and emacs-23 uses about 3X as much space as my git repo with all Emacs git branches in it). Simply doing "git clone source-repo target-repo" uses very little extra space (or time) at clone time because the objects are hard-linked across directories by default. Of course this will tend to diverge over time because new commits often won't be shared, and granularity may be a few MB due to packed objects. Still, given the amount of existing history in an Emacs repo -- most of which will never be GC'd -- I'd be surprised if the extra space took less than 5 years to reach 150MB (~50% of current Emacs repos), and I wouldn't be surprised if it took 10 years. (No, I don't have any actual data.) Also, the primary use case Eli talks about is doing synchs of stable to trunk, and the occasional cherrypick in the other direction. In this case, the "trunk" repository will have a copy of the stable branch, and in the unlikely case they diverge much, you can always "repack" the "stable" repo by fetching stable-repo into trunk-repo, then rm -rf and git clone a new stable-repo. Most of the time is taken up by rm -rf .... Whether that hack works for your favorite feature branches, I don't know (you might not want to pollute trunk with them before they're ready), but it probably does. I don't see any good reason for describing any other strategies than "if you're worried about bootstrap times, just use a second clone from your local trunk repo". If somebody really runs into a space issue, it's easy enough to explain how to reduce space usage. > The answer currently seems to be "use git-new-workdir" This should work OK 99.44% of the time in Emacs workflows, but if the new user gets frisky with rebasing or commit --amend etc, they *can* shoot themselves in the foot. If they do, they almost certainly will break a private part of the repo that cannot be recovered from public sources. I don't think that's worth it, IMHO FWIW YMMV.