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: Messing with the VC history Date: Tue, 18 Nov 2014 16:53:28 +0900 Message-ID: <878uj9uepz.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1416297253 30204 80.91.229.3 (18 Nov 2014 07:54:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2014 07:54:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Brinkhoff Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 18 08:54:05 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 1Xqdbv-000097-FN for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 08:54:03 +0100 Original-Received: from localhost ([::1]:51720 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqdbv-0000FX-4V for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 02:54:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqdbc-0000Dj-L6 for emacs-devel@gnu.org; Tue, 18 Nov 2014 02:53:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqdbV-0000sQ-5L for emacs-devel@gnu.org; Tue, 18 Nov 2014 02:53:44 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:44660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqdbU-0000oY-Sp for emacs-devel@gnu.org; Tue, 18 Nov 2014 02:53:37 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 8BD2C1C3937; Tue, 18 Nov 2014 16:53:28 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 741A21A2844; Tue, 18 Nov 2014 16:53:28 +0900 (JST) In-Reply-To: <85ppcl6knw.fsf@junk.nocrew.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:177523 Archived-At: Lars Brinkhoff writes: > Stephen J. Turnbull wrote: > > John Yates wrote: > > > Are they under the impression that by contrast a merge absolves > > > them of any need to run tests? > > > > Of course not! They know for a fact that they already ran them on > > the revisions in their feature branch and on the merged code, and > > that the rebased revisions will be *different* from the revisions > > they ran tests on. They object to running the tests *twice* when > > once should do. > > I've met some of those. Is there a counterargument? (I'm not sure what you're asking. HTH) It depends on the purpose of the tests. - If the purpose of the tests is to ensure that *released* code is "clean", then you only need to test the merge version. No problem, rebase and test when you feel like it. :-) - If the purpose of the tests is to ensure that each revision in the DAG is "clean" (eg, in order to make bisect as accurate as possible), then it substantially reduces time and annoyance for the the developer to test each change in the feature branch then *merge* and test the merge commit. This case basically comes down to a vote between the "pretty DAG" folks and the TDD crowd.[1] - If the purpose of the tests is to ensure that each commit in the DAG is "clean" in the context of the latest revision before yours, then it makes sense to rebase and test each revision in the rebased branch. You only do as much testing on the feature branch as gives you confidence you won't have to do much debugging and repair for rebased commits. In this case there is no conflict between rebasing and thorough testing. Personally, I'm kinda OCD and tend toward Type C most of the time. (I've also read and understand the git documentation. You see my problem, I think. :-) I find bisect very useful on occasion, so would rule out Type A if at all possible. But I find Type B plausible, and think it's a matter of taste. Footnotes: [1] However, some people think a mainline with only merge commits on it is pretty, and they just oppose rebasing on principle.