From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Change to bzr build instructions Date: Fri, 25 Mar 2011 14:52:33 +0100 Organization: Organization?!? Message-ID: <87wrjn1f4u.fsf@fencepost.gnu.org> References: <30r5a1s4kt.fsf@fencepost.gnu.org> <83fwqbtthq.fsf@gnu.org> <87aagj349j.fsf@fencepost.gnu.org> <83d3lftsf7.fsf@gnu.org> <83bp0ztkbl.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1301062141 2785 80.91.229.12 (25 Mar 2011 14:09:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2011 14:09:01 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 25 15:08:57 2011 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 1Q37h9-0005ot-40 for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2011 15:08:55 +0100 Original-Received: from localhost ([127.0.0.1]:39194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q37dd-0006RQ-33 for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2011 10:05:17 -0400 Original-Received: from [140.186.70.92] (port=53577 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q37WO-0003oe-GJ for emacs-devel@gnu.org; Fri, 25 Mar 2011 09:58:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q37Rb-0008GD-Nx for emacs-devel@gnu.org; Fri, 25 Mar 2011 09:52:52 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:39923) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q37Rb-0008FP-E7 for emacs-devel@gnu.org; Fri, 25 Mar 2011 09:52:51 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q37RY-0002hN-S7 for emacs-devel@gnu.org; Fri, 25 Mar 2011 14:52:48 +0100 Original-Received: from p508ecfdf.dip.t-dialin.net ([80.142.207.223]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2011 14:52:48 +0100 Original-Received: from dak by p508ecfdf.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Mar 2011 14:52:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 34 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508ecfdf.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:VXRrR7CkqNFe5N3LP0/h1PdZTZM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:137676 Archived-At: Eli Zaretskii writes: >> From: Leo > >> Why would bzr insist people remember to use bzr mv instead of the >> shell command mv? > > Because that way, there's no heuristics involved in inferring whether > a file was renamed or not. With bzr, renaming while also modifying > the file's contents can be safely done in one commit instead of two. Safety does not come into play here. You can, of course, do the same in git. If you do this frequently, it makes sense to tell git to work harder when reconstructing history. When you do, git can also make sense out of material factored out from several files into a single one and vice versa, something which can't be told bzr as far as I know. Of course, you need to _know_ when it will be helpful to ask for more, and it might be an easier choice for the person actually doing the checkin. While it is usually easier to ask an automated tool for working harder right now than a human, as long as the respective information is likely to be read more often than written, letting the human do the work while he still has complete knowledge about what he is doing is a reasonable tradeoff. The problem is when people consider it likely that nobody will actually need this information: in that case still writing it requires discipline. And Eli asked for keeping this discipline because it makes life easier in the long run given our choice of tools. -- David Kastrup