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: Tue, 25 Nov 2014 03:18:53 +0900 Message-ID: <877fyksbqq.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> <87k32mrlyn.fsf@uwakimon.sk.tsukuba.ac.jp> <83zjbgprax.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 1416853185 20099 80.91.229.3 (24 Nov 2014 18:19:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Nov 2014 18:19:45 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 24 19:19:38 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 1XsyEc-0001id-1W for ged-emacs-devel@m.gmane.org; Mon, 24 Nov 2014 19:19:38 +0100 Original-Received: from localhost ([::1]:53930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsyEb-0004I4-6L for ged-emacs-devel@m.gmane.org; Mon, 24 Nov 2014 13:19:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsyER-0004H7-Gy for emacs-devel@gnu.org; Mon, 24 Nov 2014 13:19:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsyEK-0001yT-11 for emacs-devel@gnu.org; Mon, 24 Nov 2014 13:19:27 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:48345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsyE6-0001vR-N3; Mon, 24 Nov 2014 13:19:06 -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 0ABF71C38D2; Tue, 25 Nov 2014 03:18:54 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D950F1A2892; Tue, 25 Nov 2014 03:18:53 +0900 (JST) In-Reply-To: <83zjbgprax.fsf@gnu.org> 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:178196 Archived-At: Eli Zaretskii writes: > It would be more fair to compare the .bzr subdirectory of the Bazaar > repository with the .git subdirectory of the Git repository, in which > case Git wins with a 1:2 ratio That's what I mean by "repo", and that's what I did. Looking more closely, I see some obsolete-packs which account for 1/3 of the space. However, I've not made any commits to those branches, so they came with the original clone somehow. > > 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. > > That is true (even on Windows), but then one would need to pull twice, > once from upstream, the other time from the first clone to the second, > right? Doesn't sound a net win to me. Fetching takes negligible time locally, and if you're worried about the typing write a shell function/script or an Emacs command. OTOH, if the merge part of pull breaks, it would break anyway, and you have to fix that. I think there's a huge amount of premature optimization going on here (not from you: "make bootstrap" is an unacceptable time sink if you can avoid it, finding ways to avoid it is not "premature"). Both the space worries of people less experienced with git and the workflow proposals of the experienced users really should be postponed until the new git users actually run into those issues.