From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: VC and bzr. Date: Thu, 22 Apr 2010 16:58:55 +0200 Message-ID: <87633j5ya8.fsf@telefonica.net> References: <4BCF45FA.1060808@swipnet.se> <4BCFDE02.5090808@swipnet.se> <4BD01AC9.1000200@swipnet.se> <4BD0395F.7040500@swipnet.se> <87eii7629z.fsf@telefonica.net> <87aasv5zsz.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1271948374 24801 80.91.229.12 (22 Apr 2010 14:59:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Apr 2010 14:59:34 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 22 16:59:31 2010 connect(): No such file or directory 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 1O4xsG-0000qu-QQ for ged-emacs-devel@m.gmane.org; Thu, 22 Apr 2010 16:59:31 +0200 Original-Received: from localhost ([127.0.0.1]:56636 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4xsC-0005qv-Ua for ged-emacs-devel@m.gmane.org; Thu, 22 Apr 2010 10:59:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4xs8-0005qg-Mk for emacs-devel@gnu.org; Thu, 22 Apr 2010 10:59:20 -0400 Original-Received: from [140.186.70.92] (port=50978 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4xs6-0005qU-Ne for emacs-devel@gnu.org; Thu, 22 Apr 2010 10:59:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4xs2-0003b6-Mf for emacs-devel@gnu.org; Thu, 22 Apr 2010 10:59:17 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:56838) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4xs2-0003ao-8e for emacs-devel@gnu.org; Thu, 22 Apr 2010 10:59:14 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O4xry-0000gQ-Hg for emacs-devel@gnu.org; Thu, 22 Apr 2010 16:59:10 +0200 Original-Received: from 83.42.12.8 ([83.42.12.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2010 16:59:10 +0200 Original-Received: from ofv by 83.42.12.8 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2010 16:59:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ connect(): No such file or directory Original-Lines: 37 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 83.42.12.8 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:gSAL8Hemw4hlfSTHIkJXHcRDAcU= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:124049 Archived-At: Andreas Schwab writes: > Óscar Fuentes writes: > >> We are talking about `push' here. `bzr push' works only if a >> fast-forward is possible. Same for `bzr pull'. From my reading of the >> man pages, git doesn't merge on `push' either. > > So it works exactly like git. You commit/merge locally and push when > ready. That's one of the basic points of a DCVS. I'm trying to convey this to you, but failing miserably at it: * Merge point * Feature 1 * Feature 2 * Feature 3 * Previous stuff Following your advice, that's how the history would look on bzr. People using `log' without extra switches, or reading the emacs-diffs ml, will see just * Merge point * Previous stuff Now you would argue that those extra switches should be added via aliases or wathever to `log' so they are always on, but then you will face another problem with bzr: it is very difficult to rewrite history (no good rebasing facilities, etc) so it is hard to rewrite your feature branch into a nice series of commits for they looking good after integrated upstream. Hence, people merge their feature branches as they were created and this implies that the stuff shown by `bzr log -n0' is not all that interesting. That means that `bzr log -n0' would end as a mess of interesting and trivial stuff, but `bzr log' would hide key developments.