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: base Date: Sun, 29 Aug 2010 01:25:45 +0900 Message-ID: <87iq2u4sc6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20100822120642.GA1794@muc.de> <871v9o7dmf.fsf@uwakimon.sk.tsukuba.ac.jp> <87wrrg5rzg.fsf@uwakimon.sk.tsukuba.ac.jp> <87r5ho5gyr.fsf@uwakimon.sk.tsukuba.ac.jp> <87hbij6hib.fsf@uwakimon.sk.tsukuba.ac.jp> <87k4nf7ezq.fsf@catnip.gol.com> <878w3v7dd2.fsf@catnip.gol.com> <83wrrfmljv.fsf@gnu.org> <87d3t75crc.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwy2g7i2.fsf@telefonica.net> <83r5hmmrz0.fsf@gnu.org> <877hjefll8.fsf@telefonica.net> <83mxsam5lh.fsf@gnu.org> <87eidm5a0n.fsf@catnip.gol.com> <87y6bt4p01.fsf@uwakimon.sk.tsukuba.ac.jp> <83iq2xmhd6.fsf@gnu.org> <87r5hk438u.fsf@uwakimon.sk.tsukuba.ac.jp> <838w3smacr.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1283013006 9950 80.91.229.12 (28 Aug 2010 16:30:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 28 Aug 2010 16:30:06 +0000 (UTC) Cc: emacs-devel@gnu.org, miles@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 28 18:30:04 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OpOI7-0003B3-Tf for ged-emacs-devel@m.gmane.org; Sat, 28 Aug 2010 18:30:04 +0200 Original-Received: from localhost ([127.0.0.1]:44109 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OpOI6-0002A0-IB for ged-emacs-devel@m.gmane.org; Sat, 28 Aug 2010 12:30:02 -0400 Original-Received: from [140.186.70.92] (port=52243 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OpOI0-000283-7K for emacs-devel@gnu.org; Sat, 28 Aug 2010 12:29:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OpOHy-0005VX-QL for emacs-devel@gnu.org; Sat, 28 Aug 2010 12:29:56 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:57497) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OpOHw-0005SV-RS; Sat, 28 Aug 2010 12:29:53 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4ABA1F4003; Sun, 29 Aug 2010 01:29:48 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id 3A1E1F4002; Sun, 29 Aug 2010 01:29:48 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 2BBFD3FA0287; Sun, 29 Aug 2010 01:29:48 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 88F391A47CA; Sun, 29 Aug 2010 01:25:45 +0900 (JST) In-Reply-To: <838w3smacr.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:129345 Archived-At: Eli Zaretskii writes: > No, I meant use-cases that are of interest to ordinary users, as > opposed to technicians. Sure, but what about the case of "I want this feature, but no other crap"? Why wouldn't that be of interest to an ordinary user? In git, that's simple to express: git rebase --onto my-branch feature-parent feature-branch You do need to know which branch is feature-parent, but gitk will tell you that with "gitk --all". You only need to be able to see the green tags in gitk, and trace your branch of interest back to its node and up again to a tag (and any such tag will do -- although it requires some understanding of DAGs to know *why*, this means it's hard for a naive user to make a mistake here). So doing this is not beyond an ambitious but non-technical user at all. *Explaining how* to do it, though, requires some knowledge. The point of this whole subthread is that the git model makes this easy (for the technician) to think about. It is not easy to think about this in bzr, and harder to implement. You wave your hands and say "I'm sure it can be done with merge". Well, I'm pretty sure too, but I'm also sure I'd have to ask Robert Collins to tell me how. > Why bother [with colocated branches], if you can easily branch and > work in a separate tree? Because I *don't like* working in a separate tree for *some* purposes, although I readily create separate workspaces (in git) for others. Why should power users have to put up with these limitations? > And I don't see any reason to "understand the DAG", either. What's > to understand, anyway? It's not a big deal to "understand the DAG," of course. You can just see it with the appropriate tool (and all VCSes supply such a tool). What's useful is to understand how user-level concepts like "features" map to the DAG, and how your VCS can manipulate DAG parts that (may or may not) correspond to user-level features. > I know what a DAG is, and I think I have some idea what "bzr merge" > does to a history. Oh? Suppose that branch foo has 4 revisions and branch bar has only the first one. Now do "bzr merge -r2..4 ../foo; bzr commit -m merge" in branch bar. What does "bzr log -n0" show? I was surprised (and disappointed, although I understand why it happened once I saw the result). #! /bin/bash pushd /tmp; mkdir test; cd test mkdir foo; cd foo; bzr init addfile () { echo $1 > $1; bzr add $1; bzr commit -m "add $1"; } addfile foo bzr branch . ../bar addfile bar addfile baz addfile quux cd ../bar bzr merge -r2..4 ../foo; bzr commit -m merge bzr log -n0 Did you predict the output correctly?