From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91130 invoked by alias); 28 Dec 2019 02:27:45 -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 91116 invoked by uid 89); 28 Dec 2019 02:27:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:6ad79ec, H*MI:sk:6ad79ec, H*i:sk:6ad79ec, pain 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; Sat, 28 Dec 2019 02:27:43 +0000 Received: by snark.thyrsus.com (Postfix, from userid 1000) id 3A9FF4704CF0; Fri, 27 Dec 2019 21:27:42 -0500 (EST) Date: Sat, 28 Dec 2019 02:27:00 -0000 From: "Eric S. Raymond" To: "Richard Earnshaw (lists)" Cc: Joseph Myers , Jakub Jelinek , Maxim Kuvyrkov , GCC Development , Alexandre Oliva , Jeff Law , Segher Boessenkool , Mark Wielaard Subject: Re: Proposal for the transition timetable for the move to GIT Message-ID: <20191228022742.GB22756@thyrsus.com> Reply-To: esr@thyrsus.com References: <20191226111633.GJ10088@tucnak> <5DCEA32B-3E36-4400-B931-9F4E2A8F3FA5@linaro.org> <20191226183553.GK10088@tucnak> <6ad79ec1-5a2e-fd88-6c3c-832feaea5caf@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ad79ec1-5a2e-fd88-6c3c-832feaea5caf@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00463.txt.bz2 Richard Earnshaw (lists) : > Well, personally, I'd rather we didn't throw away data we have in our > current SVN repo unless it's unpresentable in the final conversion. I agree with this philosophy. You will have noticed by now, I hope, that reposurgeon peserves as much as it can, leaving deletions to be a matter of user policy. In the normal case, reposurgeon could save its users a significant amount of work by being more aggressive about automatically deleting remnant bits that are merely *very unlikely* to be useful. I deliberately refused to go thar route. > Merge info is not one of those cases. Sometimes. Some Subversion mergeinfo operations map to Git's branch-centric merging. Many do not, corresponding to cherry-picks that cannot be expressed in a Git history. Reposurgeon does a correct but not complete job of translating mergeinfos that compose into branch merges. It handles the simple, cmmon cases and punts the tricky ones. More coverage would theoretically be possible, but I don't have the faintest clue what a general resolution rule would look like. Except I'm pretty sure the problem is bitchy-hard and the solution really easy to get subtly wrong. Frankly, I don't want to touch this mess with insulated tongs. Somebody would have to offer me serious money to compensate for the expected level of pain. -- Eric S. Raymond