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 04:16:16 +0900 Message-ID: <87fwxy4kfz.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> <87iq2u4sc6.fsf@uwakimon.sk.tsukuba.ac.jp> <83lj7qlk1r.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 1283023237 13214 80.91.229.12 (28 Aug 2010 19:20:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 28 Aug 2010 19:20:37 +0000 (UTC) Cc: miles@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 28 21:20:35 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 1OpQx7-0004PN-22 for ged-emacs-devel@m.gmane.org; Sat, 28 Aug 2010 21:20:33 +0200 Original-Received: from localhost ([127.0.0.1]:55142 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OpQx6-0005Ud-Fq for ged-emacs-devel@m.gmane.org; Sat, 28 Aug 2010 15:20:32 -0400 Original-Received: from [140.186.70.92] (port=37929 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OpQx1-0005UW-H5 for emacs-devel@gnu.org; Sat, 28 Aug 2010 15:20:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OpQx0-0007X4-AS for emacs-devel@gnu.org; Sat, 28 Aug 2010 15:20:27 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:59163) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OpQwy-0007Wh-BU; Sat, 28 Aug 2010 15:20:24 -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 5D8AAF4003; Sun, 29 Aug 2010 04:20:20 +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 4D527F4002; Sun, 29 Aug 2010 04:20:20 +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 482563FA0287; Sun, 29 Aug 2010 04:20:20 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id AA44F1A47CA; Sun, 29 Aug 2010 04:16:16 +0900 (JST) In-Reply-To: <83lj7qlk1r.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:129354 Archived-At: Eli Zaretskii writes: > > 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 No, it's not that simple. You need to specify three things which can vary more or less independently: the first version to rebase, the last version to rebase, and where to rebase them. The bzr syntax only allows two of the three: the current branch, and the point at which to rebase. It *can't* work in the general case. > (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. That does the wrong thing. Although it merges the right content, it loses all the history. > > *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. Then you have *real* problems, because you think you know what you're doing, but you don't. Of course, it's possible that your model is sufficient for your purposes. Maybe you don't use rebase at all, or maybe history loss doesn't bother you in this case. Good for you! But that makes your input into discussions of *project* workflow quite suspect, because your advice is at best irrelevant, and at worst wrong, for what some of your colleagues want to do. > > 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. Good for you. But why should your preferences rules *my* workflow? It's not a question of disk space. It's a question of preferred workflow. I like git's colocated model for some purposes, like a quick switch to a branch for accumulating typo fixes, or recording alternative specifications of a feature and their implementations. I also like it because it allows me to group some branches that are related together, and add or delete branches as they become (ir)relevant to that task, then clone the whole thing to a difference host, or offer it to a colleague. > > 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. Yes, it does that ... for the content. However, it forgets the history N1..N2 which was just applied, which is undesirable for two reasons: first, I want to see it with an ordinary log command (not switching branches), and second, at least in theory the VCS should be able to use that information to avoid merge conflicts in the future should that branch be merged again. > 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. No, I mean the output of bzr log -n0. In particular, were you expecting that the history of changes you just merged would just vanish into thin air?