From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90420 invoked by alias); 19 Nov 2019 19:32:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 90380 invoked by uid 89); 19 Nov 2019 19:32:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*MI:sk:ba76e23, H*i:sk:ba76e23, H*f:sk:ba76e23, our X-HELO: snark.thyrsus.com Received: from thyrsus.com (HELO snark.thyrsus.com) (71.162.243.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Nov 2019 19:32:23 +0000 Received: by snark.thyrsus.com (Postfix, from userid 1000) id E16724704895; Tue, 19 Nov 2019 14:32:21 -0500 (EST) Date: Tue, 19 Nov 2019 19:32:00 -0000 From: "Eric S. Raymond" To: "Richard Earnshaw (lists)" Cc: Nicholas Krause , Segher Boessenkool , law@redhat.com, gcc@gcc.gnu.org Subject: Re: Commit messages and the move to git Message-ID: <20191119193221.GA3834@thyrsus.com> Reply-To: esr@thyrsus.com References: <20191118171115.GI16031@gate.crashing.org> <8c32c288-e9e6-b01b-7911-3f186116da85@gmail.com> <7c86495c-dcf9-e4a4-8d7a-4f1112dbc699@gmail.com> <73b65011-60f3-dd9e-b3b4-296090f27ddc@gmail.com> <9113691d-5a64-5afe-a2ec-f10e9626a2bc@gmail.com> <1e5f3823-d71f-7429-4a28-84e8532f80f8@arm.com> <20191119112409.GA125265@thyrsus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00148.txt.bz2 Richard Earnshaw (lists) : > I was looking at the reposurgeon code last night, and I think I can see what > the problem *might* be, but I haven't had time to produce a testcase. > > Some of our commits have mergeinfo that looks a bit like this: > > 202022-202023,202026,202028-202029,202036,202039-202041,202043-202044,202048-202049,202051-202056,202058-202061,202064-202065,202068-202071,202077,202079-202082,202084,202086-202088,202092-202104,202106-202113,202115-202119,202121,202124-202134,202139,202142-202146,202148-202150,202153-202154,202158-202159,202163-202165,202168,202172,202174,202179-202180,202184-202192,202195,202197,202202-202208,202225-202230,202232-202233,202237-202239,202242,202244-202245,202247,202250-202251,202258-202264,202266,202269,202271-202275,202279,202281-202282,202284,202286,202289-202292,202296-202299,202301-202302,202305,202309,202311-202323,202327-202335,202337,202339,202343-202346,202350,202352,202356-202357,202359-202360,202363-202371,202373-202374,202377,202379-202382,202384,202389,202391-202395,202398-202407,202409,202411,202416-202418,202421 > > which is a massive long list with a number of holes in it. > > But I suspect the holes are really commits to other branches and that in the > above describes a linear chain along one branch. If so, rather than > producing links to each subgroup (and perhaps dropping single non-list > elements, the description can be mapped back to a contiguous sequence of > commits down a branch and thus should really resolve to a single child being > used for the merge source. At present, I think for the above we're seeing a > child reference created for each subrange in that list. I have no doubt you are correct. Detecting such interrupted ranges ia foing to be... interesting. > Incidentally, the mergeinfo pass on the gcc repo is currently taking about 8 > hours on my machine, that's 80-90% of the entire conversion time. But it > might be related to the above. You must be running the old Python code, there was on O(n**2) in that phase that has since been fixed. Try the Go code from https://gitlab.com/esr/reposurgeon; it is *much* faster. -- Eric S. Raymond