From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: New test files in emacs-25 branch Date: Thu, 03 Dec 2015 22:13:24 +0200 Message-ID: <83fuzji93v.fsf@gnu.org> References: <83k2ovix06.fsf@gnu.org> <87lh9bo1wp.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1449173653 14602 80.91.229.3 (3 Dec 2015 20:14:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Dec 2015 20:14:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 03 21:14:02 2015 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 1a4aGP-000615-9w for ged-emacs-devel@m.gmane.org; Thu, 03 Dec 2015 21:14:01 +0100 Original-Received: from localhost ([::1]:37281 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4aGO-0002Bq-NV for ged-emacs-devel@m.gmane.org; Thu, 03 Dec 2015 15:14:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4aGA-0002Bl-7b for emacs-devel@gnu.org; Thu, 03 Dec 2015 15:13:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4aG4-0004Hq-SK for emacs-devel@gnu.org; Thu, 03 Dec 2015 15:13:46 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:43832) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4aG4-0004HS-Ki for emacs-devel@gnu.org; Thu, 03 Dec 2015 15:13:40 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NYS00600T8ZZ300@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Thu, 03 Dec 2015 22:13:39 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYS0063NTIRU260@a-mtaout20.012.net.il>; Thu, 03 Dec 2015 22:13:39 +0200 (IST) In-reply-to: <87lh9bo1wp.fsf@russet.org.uk> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:195829 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: > Date: Thu, 03 Dec 2015 17:52:22 +0000 > > Eli Zaretskii writes: > > > I guess new test files introduced on the emacs-25 branch will have to > > be manually added to the corresponding directory on master, since > > gitmerge.el won't be able to pull such trickery, right? > > I guess this crossed my mind sometime after I offered to move all the > file locations. Probably it would have made sense to leave things till > after the emacs-25. It wouldn't have mattered. Emacs 25.1 is not going to be the only version delivered from the emacs-25 branch. > If this is going to be a major PITA (and it probably is), one solution > would be to create a "test/automated" directory on master. It's not a PITA. For a rare event such as this one, committing twice is not a catastrophe. I just wanted to be sure there are no better ideas. > Is git is intelligent enough to work through a file move? Will new tests > added to existing test files in the automated directory of emacs-25 > merge into the moved files on master? That should work, but I wasn't talking about this. I was talking about adding new files to emacs-25. > If so, then new files in emacs-25 test/automated can be merged to > master, and then moved to the new directory structure any time on > master, and new tests or changes should follow. That's error prone, so I'd rather we avoided it.