From owner-freebsd-git@freebsd.org Tue Feb 21 23:47:57 2017 Return-Path: Delivered-To: freebsd-git@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFD27CE865F for ; Tue, 21 Feb 2017 23:47:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 915101E0E for ; Tue, 21 Feb 2017 23:47:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id l66so33415160ioi.1 for ; Tue, 21 Feb 2017 15:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XNqiQzoInTVBj+HNNDNc7HIOWVPd9XdAtxTTtbbZzVA=; b=Takvo8fw4sRDPQP4q467nia3yncdXF3YHoiYfTLif3txllog8dtT2QvUT/p0pErJD2 8FfUdMOKByfJpR2EklLhUflzWpOnWe6C77+jQpOj/M+N+d+T8ZnU3AaowvdVZdKKxK+c OYrW8AQnoWh3MWtXj9lwyt51EL2WyQaFrZit1r3XXFJaiB1KWnKYaCOM3s/MgJRpTujP cFUqOBLWQ1tt65hHSsYwWMr4D4ZpAppPrsYgHEj/TZ265wPKET9rLD/Uj3UF46zZOZE+ E2jFztgwEmfP+ryiWTMMPmt1D0U/aZfv1bFTupWOyuSbX2Ehq2mz5Tr4PF+YnCYPQN9E kNww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XNqiQzoInTVBj+HNNDNc7HIOWVPd9XdAtxTTtbbZzVA=; b=a1HKxg52OoIGmv5DHHemW1/1lREToKVG2/BbMbiDtARraqmCLugmzhvkGzN4Ef80ac KrYZWR9gpJRalP8azkYj+uwycJvlwqmofrSUPVUBgPCI6+W6245ZMwVlF28142fiiFBe 7ok0J9Lku50Fw/8WtUzy9A4gI73bEocyclCJbeyTCelbL243ddSWKt+0iJ5dmswdos1H 5XrySzvgH3K09psFhbZiAy7GkDR43bQQ211/rbWqlTG+2M2bqUbF0FQjMg3eTTDT00ZD 9HpGbY5dYIHlQwvDN3RCL/UzRlx1XuhvLRpbQ0paSRulD+axrozkLt/+VjhKAKgFsUm7 axWw== X-Gm-Message-State: AMke39ncPfh/q9lVaMYxBEbHBpCCoKsYXUCbmSuiYtJFchAEr36KBZ6P8bGCacNQ6tUWqIRYwcLYyzjatn3kQA== X-Received: by 10.107.198.195 with SMTP id w186mr21916135iof.19.1487720876618; Tue, 21 Feb 2017 15:47:56 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.132 with HTTP; Tue, 21 Feb 2017 15:47:56 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> From: Warner Losh Date: Tue, 21 Feb 2017 16:47:56 -0700 X-Google-Sender-Auth: Uo-k4zClGE_E63U6BRPbztGLoSQ Message-ID: Subject: Re: Reconsider switching from svn to git? To: Ed Maste Cc: freebsd-git@freebsd.org, =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 23:47:57 -0000 On Tue, Feb 21, 2017 at 1:22 PM, Ed Maste wrote: > On a different (non-public) list we've been discussing git in FreeBSD, > and I wanted to discuss one of Warner's points further. Before asking > I asked for approval to quote the message here. > > On 21 February 2017 at 11:36, Warner Losh wrote: >> >> However, there's one big drawback we don't have with svn: it destroys >> history. Rebasing branches destroys history, as does deleting >> branches. In svn, you can always get that information back, but not so >> with git. It's very easy to do these operations and quite difficult to >> undo them. > > I'd like to understand this better. In my opinion, in general > commit(s) should stand alone -- any metadata associated with the > commit (PR numbers, review links, etc.) should be in the commit > message itself. The fact that they were originally done on a branch > should only be an "implementation detail." So I agree rebasing and > committing loses that history, but think in general it should not > matter. For small commits, I agree. For longer lived project branches, however, there can be issues. Specifically, in svn, when you delete a branch, it just marks it as empty, but you can get back to it at any point in the branch. In git, however, deleting a branch deletes the meta-data needed to get back to the branch (as does rebasing). We'd need some way to administratively prohibit this, perhaps, for the source of truth repo. I have no clue if this is possible with git, just putting it out there. There's also a number of advantages / disadvantages to merging vs rebasing + fast-foward to pushing changes upstream. I'm curious what people are thinking here. >> If, and this is a big if, we go to using git, I'd like to *STRONGLY* >> request that we not change the hashes we have on github today. There's >> lots of people with branches from that and changing the hashes would >> make them all useless. Well, not completely useless, but quite >> difficult to recover from unless the branches were simple without >> merges. > > This is a very tricky issue. I agree that there's a(n incredibly) > large cost with changing existing hashes, and previously argued that > it was an absolute nonstarter. Also, I think this is independent of > switching to git as the source of truth: we have the same open issue > with the current svn2git mirror. I know. I know the pain it will cause for Netflix should that issue be resolved. > That said, I also strongly believe that, as long as SVN is the "source > of truth" repo, the git conversion must be reproducible by third > parties. I believe developers and others who consume FreeBSD via git > must be able to validate that the data and metadata are consistent > between svn and git. Unfortunately today even the subversion mirrors > (svn.freebsd.org) have inconsistent metadata relative to > repo.freebsd.org, so it's not currently possible for end users to > validate the svn2git conversion. As one of the users that would be affected by hash changes, I'm finding that argument less persuasive given the pain I know it will cause. > I've briefly discussed with uqs@ what it would entail to migrate to a > "fixed" view of the history, and believe it's possible to facilitate a > relatively painless migration. It could look roughly like: > > 1. Broadly announce the plan > 2. Make a new alias for current master (e.g. master-legacy) > 3. Start a new, reproducible conversion and push to a new master (master-ng) > 4. As new commits are made to SVN update both master-ng and master-legacy > 5. Provide guidance on migrating both rebase- and merge-based > workflows to master-ng > 6. Give notice of upcoming switch in what master points to > 7. Switch master from master-legacy to master-ng > 8. Stop updating master-legacy if/when it becomes infeasible to > continue doing so, or when it's no longer used If there were tools to help migrate, that would be useful. But I'm unsure what those might be since many of git's most powerful features don't work when you don't have a proper shared ancestor that's recent. Though a plan like that might be able to mitigate some of our concerns given the rather quirky way we import sources at Netflix (we do them as a subtree and do odd things to create merge points). It would take some experimentation to be able to know if this is a viable path forward. Our master tree is a twisty maze of commits, merges, etc that bedevil automation. As for switching source of truth, what's the thinking on $FreeBSD$ and the currently nice property of it that it includes the branch / release in the path. Anyway, don't take concerns I have for opposition to a switch, just nerves that need to be quelled a bit first :) Warner