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: Fri, 27 Aug 2010 22:03:13 +0900 Message-ID: <87r5hk438u.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1282915482 32362 80.91.229.12 (27 Aug 2010 13:24:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 27 Aug 2010 13:24:42 +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 Fri Aug 27 15:24:41 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 1Ooyv5-0000R3-MQ for ged-emacs-devel@m.gmane.org; Fri, 27 Aug 2010 15:24:36 +0200 Original-Received: from localhost ([127.0.0.1]:32971 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ooyv5-0005MF-3K for ged-emacs-devel@m.gmane.org; Fri, 27 Aug 2010 09:24:35 -0400 Original-Received: from [140.186.70.92] (port=52088 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ooyuu-0005Lj-OQ for emacs-devel@gnu.org; Fri, 27 Aug 2010 09:24:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ooyup-0005jy-N9 for emacs-devel@gnu.org; Fri, 27 Aug 2010 09:24:24 -0400 Original-Received: from [130.158.254.171] (port=57109 helo=dmail02.cc.tsukuba.ac.jp) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ooyuj-0005hg-G6; Fri, 27 Aug 2010 09:24:13 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (unknown [130.158.254.130]) by dmail02.cc.tsukuba.ac.jp (Postfix) with ESMTP id 0C40EF5BC4; Fri, 27 Aug 2010 22:07:25 +0900 (JST) Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9B49AF4003; Fri, 27 Aug 2010 22:07:06 +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 8B249F4002; Fri, 27 Aug 2010 22:07:06 +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 8710E3FA0273; Fri, 27 Aug 2010 22:07:06 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 687E94D27A; Fri, 27 Aug 2010 22:03:13 +0900 (JST) In-Reply-To: <83iq2xmhd6.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:129299 Archived-At: Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > > Cc: Miles Bader , > > emacs-devel@gnu.org > > Date: Thu, 26 Aug 2010 20:01:02 +0900 > > > > Eli Zaretskii writes: > > > > > You are pushing a simple request ad absurdum. I wasn't asking > > > for an exhaustive list of _all_possible_ workflows, only for a > > > few representative ones. And please don't tell me that's > > > impossible, or even hard, because today I can easily do that > > > for Bazaar. > > 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). > > That's far from providing representative workflows that would be > > enough to convince anyone who has actually used git that bzr is a > > half-adequate replacement. > Indeed, I see no reason to ask for workflows that convince not to > use bzr in a project that uses bzr. Lack of some workflows I use frequently in git is certainly the most important reason why I avoid bzr. It will certainly inhibit me from contributing code to Emacs in the near to medium term. Maybe you think that is a good thing? > > For example, suppose I ask, "How do I efficiently switch from one > > branch to another in the same directory, like I do in git?" > > 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. Obviously I just used ordinary branches to get that error. 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. (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. > > Or "how do I rebase branch A from the common ancestor with branch > > B to the grandparent of the head of branch C, which branched from > > trunk before B did?" > > 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. So, what was that all about? 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 don't think it's reasonable to ask anybody to explain how to achieve that result based on a few memorized workflows, and without reference to the DAG. However, the DAG-based description, and its git implementation should give me a close approximation to what I really want. The git implementation is straightforward: git rebase --onto C~2 B A (or "git checkout A; git rebase --onto C~2 B"). > Note that the acronym DAG is not used anywhere. OK, you got me on that one. 1 out of 3 ain't bad. :-)