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: Messing with the VC history Date: Tue, 18 Nov 2014 09:41:19 +0100 Organization: Organization?!? Message-ID: <87ioicj3yo.fsf@fencepost.gnu.org> References: <87k32vsm8u.fsf@wanadoo.es> <83fvdjdv8t.fsf@gnu.org> <871tp3rv07.fsf@wanadoo.es> <87lhnavhz9.fsf@uwakimon.sk.tsukuba.ac.jp> <87ioiev7bp.fsf@uwakimon.sk.tsukuba.ac.jp> <85ppcl6knw.fsf@junk.nocrew.org> <878uj9uepz.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416300125 9913 80.91.229.3 (18 Nov 2014 08:42:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2014 08:42:05 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 18 09:41:58 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XqeMH-0000Hi-Pd for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 09:41:57 +0100 Original-Received: from localhost ([::1]:51850 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqeMH-00017X-Ac for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 03:41:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34741) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqeLz-00017L-LC for emacs-devel@gnu.org; Tue, 18 Nov 2014 03:41:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqeLt-00009K-Bj for emacs-devel@gnu.org; Tue, 18 Nov 2014 03:41:39 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:54765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqeLt-00009F-5L for emacs-devel@gnu.org; Tue, 18 Nov 2014 03:41:33 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XqeLr-00007Y-GE for emacs-devel@gnu.org; Tue, 18 Nov 2014 09:41:31 +0100 Original-Received: from x2f41f1e.dyn.telefonica.de ([2.244.31.30]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Nov 2014 09:41:31 +0100 Original-Received: from dak by x2f41f1e.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Nov 2014 09:41:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 28 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f41f1e.dyn.telefonica.de 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/25.0.50 (gnu/linux) Cancel-Lock: sha1:3JThqju2XBij5O4rNmc/OPb3V28= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177528 Archived-At: "Stephen J. Turnbull" writes: > [1] However, some people think a mainline with only merge commits on > it is pretty, and they just oppose rebasing on principle. "Beauty" as an underlying concept of "pretty" usually involves perfection, and perfection in technical settings implies everything having a purpose. A merge commit is a branch that starts off somewhere and ends somewhere. If there is no point to where the branch starts off, the branch start is ugly, never mind whether you consider a merge in itself pretty. An example for a merge commit in a pretty-based development environment would be . A merge commit is used because not all intermediate states in the logically separate commits may be compilable (either they are known to be uncompilable, or the jury is out on them). Even through the commit sequence itself has been "prettified" by structuring it into separate commits doing one logical task, a merge commit is warranted in order not to cause bisection problems. The starting point of the branching point is not arbitrary: it is the parent of the merge commit. Such an incestuous merge has to be ordered explicitly using the --no-ff flag to merge. -- David Kastrup