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: Fri, 27 Aug 2010 16:52:20 +0300 Message-ID: <838w3smacr.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1282917175 7306 80.91.229.12 (27 Aug 2010 13:52:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 27 Aug 2010 13:52:55 +0000 (UTC) Cc: miles@gnu.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 27 15:52:54 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 1OozMT-000899-9u for ged-emacs-devel@m.gmane.org; Fri, 27 Aug 2010 15:52:53 +0200 Original-Received: from localhost ([127.0.0.1]:50129 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OozMS-0001nF-Qc for ged-emacs-devel@m.gmane.org; Fri, 27 Aug 2010 09:52:52 -0400 Original-Received: from [140.186.70.92] (port=48822 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OozML-0001nA-LG for emacs-devel@gnu.org; Fri, 27 Aug 2010 09:52:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OozMK-0001j2-6y for emacs-devel@gnu.org; Fri, 27 Aug 2010 09:52:45 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:36309) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OozMJ-0001iu-V6; Fri, 27 Aug 2010 09:52:44 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L7T00K00D1DPP00@a-mtaout22.012.net.il>; Fri, 27 Aug 2010 16:52:10 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.186.164]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L7T00JNHD6XMAC0@a-mtaout22.012.net.il>; Fri, 27 Aug 2010 16:52:10 +0300 (IDT) In-reply-to: <87r5hk438u.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:129302 Archived-At: > From: "Stephen J. Turnbull" > Cc: emacs-devel@gnu.org, > miles@gnu.org > Date: Fri, 27 Aug 2010 22:03:13 +0900 > > > > No, you can provide some representative workflows that are enough > > > for you. > > > Actually, I meant some representative workflows that should cover > > the common use-cases. > > By "common use cases" you evidently mean "but not anything that a git > user might want," or even "that a typical user can express in ordinary > terms and a git user could achieve by manipulating the DAG" (see below > for an example). No, I meant use-cases that are of interest to ordinary users, as opposed to technicians. > > bzr switch THE_OTHER_BRANCH > > Thank you for playing. Unfortunately, not only isn't that efficient, > it doesn't work at all without a fair amount of additional explanation: > > steve@uwakimon /tmp/test/bar $ bzr switch ../foo > bzr: ERROR: Cannot switch a branch, only a checkout. It is documented to work only with checkouts. > But it's not clear to me whether the obvious change to that workflow, > ie, checkout from "../foo" in "bar", actually has the semantics of > git, though, and I bet you have no idea either. For example, suppose > I want to merge two branches in that checkout, but preserve the > possibility of switching to either of the parents in the future. This > is trivial in git: git checkout foo; git merge bar; git branch foo^ > old-foo. The obvious solution in bzr (bzr checkout -r before:) *does > not work*; it is not a branch and you cannot commit. Some combination of "bzr merge -r" with appropriately chosen pair of revision should be able to do the trick, I think. > (At least, > that's what the dox say.) So I expect I'd have to do a bit more > preparation to get a usable approximation to git colocated branches. Why bother, if you can easily branch and work in a separate tree? > > cd A && bzr rebase --onto=revno:-3 ../C > > Thank you for playing. Unfortunately, this doesn't work in several > cases. I could get trunk commits or branch B commits I don't want. I don't understand what didn't work for you, but it could be due to bugs in `rebase'. > Translated to non-DAG terms, the scenario is "just add Miles's feature > and no extra crap". To expand a bit (but still use only commonly > understood development concepts), "I just want Drew's branch with > Miles's feature. But I don't want anything in Tom's branch that isn't > required to implement Miles's feature, I don't want any random work > done on the trunk since C branched, and I don't want the stuff that > Drew added to C in his last two commits." > > I think "just add Miles's feature and no extra crap" is a reasonable > thing to want. It probably would not occur to you to ask your VCS to > do it unless you understand the DAG, though. I see no problems doing what you want with a series of "bzr merge" commands. "bzr rebase" is simpler, but if it doesn't work, "merge" will. And I don't see any reason to "understand the DAG", either. What's to understand, anyway? I know what a DAG is, and I think I have some idea what "bzr merge" does to a history. I don't pretend being a technician, but what I know is enough for what I do. It was enough to suggest solution to your riddles, even though I never needed to do any of that. So what if some of the solutions have limitations or hit upon bugs? that's not what this was about. > 1 out of 3 ain't bad. :-) You are a darling.