From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: base Date: Sat, 28 Aug 2010 20:32:48 +0300 Message-ID: <83lj7qlk1r.fsf@gnu.org> 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> <87iq2u4sc6.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1283016667 23597 80.91.229.12 (28 Aug 2010 17:31:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 28 Aug 2010 17:31:07 +0000 (UTC) Cc: emacs-devel@gnu.org, miles@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 28 19:31: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 1OpPF4-0007VP-NA for ged-emacs-devel@m.gmane.org; Sat, 28 Aug 2010 19:30:59 +0200 Original-Received: from localhost ([127.0.0.1]:52969 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OpPF4-0004H0-6u for ged-emacs-devel@m.gmane.org; Sat, 28 Aug 2010 13:30:58 -0400 Original-Received: from [140.186.70.92] (port=59680 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OpPEv-0004FO-OP for emacs-devel@gnu.org; Sat, 28 Aug 2010 13:30:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OpPEt-0004gq-D0 for emacs-devel@gnu.org; Sat, 28 Aug 2010 13:30:48 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:35851) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OpPEt-0004ge-2k; Sat, 28 Aug 2010 13:30:47 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L7V00300HY40P00@a-mtaout20.012.net.il>; Sat, 28 Aug 2010 20:30:45 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.93.239]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L7V002POHZ8UH20@a-mtaout20.012.net.il>; Sat, 28 Aug 2010 20:30:45 +0300 (IDT) In-reply-to: <87iq2u4sc6.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:129348 Archived-At: > From: "Stephen J. Turnbull" > Cc: miles@gnu.org, > emacs-devel@gnu.org > Date: Sun, 29 Aug 2010 01:25:45 +0900 > > 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 In bzr, it's also simple: bzr rebase ../parent (modulo bugs in `rebase'). Or, if we don't want to futz with `rebase': bzr merge -rN1..N2 ../feature-branch assuming that revisions N1 to N2 introduced "the feature" on the other branch. > *Explaining how* to do it, though, requires some knowledge. I have no problems explaining why the latter works, see below. As for the former, the documentation of `rebase' seem to be clear enough, FWIW. > > 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? I don't see it as a limitation. Disk space is not at premium anymore. OTOH, the mental resources needed to remember which branch I'm on now _are_ at premium with this old fart. I prefer to see the branch name right there at the shell prompt, to serve as a reminder. > 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. "bzr merge -rN1..N2 FOO" applies to the current branch the changes introduced in revisions (N1..N2] of branch FOO. That's the simple mental model I have about "bzr merge", and it seems to work for me. For the situation you describe, it should add files `baz' and `quux', which were added in revisions 3 and 4 in branch foo. > Did you predict the output correctly? Yes, assuming you mean this output: /tmp/test/bar$ bzr merge -r2..4 ../foo; bzr commit -m merge +N baz +N quux All changes applied successfully. Committing to: /tmp/test/bar/ added baz added quux Committed revision 2.