From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: what make-dist should include [was Re: Emacs pretest 26.1.91 is out] Date: Sun, 20 Jan 2019 09:42:48 -0500 Message-ID: References: <11578.1547946527@alto> NNTP-Posting-Host: ciao.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ciao.gmane.org 1547995411 60474 195.159.176.228 (20 Jan 2019 14:43:31 GMT) X-Complaints-To: usenet@ciao.gmane.org NNTP-Posting-Date: Sun, 20 Jan 2019 14:43:31 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Mike Kupfer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 20 15:43:30 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1glEJq-000Fii-07 for ged-emacs-devel@m.gmane.org; Sun, 20 Jan 2019 15:43:26 +0100 Original-Received: from localhost ([127.0.0.1]:40707 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glEJz-0007g1-4F for ged-emacs-devel@m.gmane.org; Sun, 20 Jan 2019 09:43:35 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glEJJ-0007f3-1W for emacs-devel@gnu.org; Sun, 20 Jan 2019 09:42:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1glEJH-00077R-5J for emacs-devel@gnu.org; Sun, 20 Jan 2019 09:42:52 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:40997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glEJG-000778-W3 for emacs-devel@gnu.org; Sun, 20 Jan 2019 09:42:51 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x0KEgmwA013803; Sun, 20 Jan 2019 09:42:48 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 3A3956AA35; Sun, 20 Jan 2019 09:42:48 -0500 (EST) In-Reply-To: <11578.1547946527@alto> (Mike Kupfer's message of "Sat, 19 Jan 2019 17:08:47 -0800") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6464=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6464> : inlines <6998> : streams <1810636> : uri <2782898> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:232539 Archived-At: >> > With MQ the workflow is pretty simple: >> > >> > 1- unpack the tarball >> > 2- create the repo and commit the unpacked files >> > 3- pull the patches from their repo >> > 4- apply the patches ("hg qpush -a") >> > 5- build >> >> [ The step 0 being "download the tarball". ] >> >> Hmm... ignoring the issue of Mercurial -vs- Git, the equivalent using >> the VCS would be: >> >> 0- clone from the remote repository to a local "bare" repository. >> 1- clone from that local repository >> 2- do nothing >> 3- pull the patches from their repo >> 4- apply the patches >> 5- build > > Yeah, if all I were doing was applying static patches, there would be > less benefit to using MQ. But MQ helps with the tedium of managing a > patch repo as I refine the patches. (And I'm probably biased, since > I've been using Mercurial for over 10 years, but I only started using > Git when Emacs moved to it.) Note that steps 3-5 are 100% unchanged. > Sometime a few years ago I used a Mercurial extension to access a Git > repo. I had pretty much the same experience: it worked okay but was > kinda slow. I don't know if that extension is still available or > maintained. If the conversion to a different repository format is the problem, then I guess passing through tar is not that bad of a deal, indeed (you can get the same result by "git clone"ing and then committing the result to an Hg repository, but the benefits are not as clear). Stefan