From owner-freebsd-git@freebsd.org Wed Feb 22 00:46:30 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 74180CE5D9D for ; Wed, 22 Feb 2017 00:46:30 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 3D1781C6E; Wed, 22 Feb 2017 00:46:30 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id g18so34039503ioe.0; Tue, 21 Feb 2017 16:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=iU4dRkei/CiaT2Cb8jiTmEwOUAnY5CADLCYv4BJ2Kv8=; b=KpI5Rm82rv6eLtE02vczrtvccolJfnkEyJKCe5daq1dXSTKUkmkUstD+nyJmMhpzj8 P4AvDLjmpRlx4JfYxaDoCPc41+KWYwuDu158biXWR9rcVd7nh24v469R8TvceR+Kf4DZ Ml8Xya8gHep0aApLWeGj1tOgHAMIzfp4qeKnRI1HJWe94GtKkdV46gWtxQ801Kf5Iek+ I4BY8+kWZXIeBWUnEyGwBCEyK2hOE8cAfln86tBVDvSGK1L3s439OeI75+NF13zvMJN/ mPZmOxV8ZWM7T4Xh1S6W/rIa+Jm7lIW79TIk8okh3UBgBjIr4LJfppi+5/f0h+ReXhHn pZ+Q== 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=iU4dRkei/CiaT2Cb8jiTmEwOUAnY5CADLCYv4BJ2Kv8=; b=qXIMp6ibrqJkXtvMRoFcTMDy/Za82vzCd+/V2pjgaDzsWcRSRnVWJfeILJYRfx0PDS xMDeHzNgkLSCa2sQjMNhdytbVbxkwuqj1MnuATF/hxA9WGPKKiGnDGu864vrr760jbZx HX84ggyWfMY7UKRKlEhbmFBo/kC/4P1v2k99G9Ju6DU2o0Upf5kD8mraJOozuCaPp1CQ zhrx2m/kH999tHXneu2UcPvCrs8GSzSSMZinX91WtYwbE9qdzD7N0scvsW0DEcuexku2 5hFbSb51WXnqdICFfTy8GTwPbnKzkt5+9LBJlJiOFWBlnkUt62YoZJ8HOFTar6sEq7mq OR+g== X-Gm-Message-State: AMke39nACot6GzJ6Kgc8ORJDmFwQr1mONqugOA0Pqz46Zl9s9EsCm6oqweQilpVoPqaQGD2Fwz44n4HjH7vOtw== X-Received: by 10.107.195.73 with SMTP id t70mr5248344iof.155.1487724389580; Tue, 21 Feb 2017 16:46:29 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.39.17 with HTTP; Tue, 21 Feb 2017 16:46:09 -0800 (PST) In-Reply-To: References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> From: Ed Maste Date: Tue, 21 Feb 2017 19:46:09 -0500 X-Google-Sender-Auth: tQkm057uRHrobST2NLD6Egb6nTA Message-ID: Subject: Re: Reconsider switching from svn to git? To: Warner Losh 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: Wed, 22 Feb 2017 00:46:30 -0000 On 21 February 2017 at 18:47, Warner Losh wrote: > > 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. Ok, we could easily disallow any destructive activity on a source-of-truth git repo, including force (non-fast-forward) pushes and branch deletion. > 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. For relatively short-lived work-in-progress branches that are destined for upstream FreeBSD I prefer the rebase model, where changes are regularly rebased on HEAD. It might be more work in aggregate, and might occasionally require repeating some portions of work. But I like having a set of changes as a logical sequence ready to apply to head. I hope others who maintain long-lived divergent branches not destined for upstream FreeBSD can weigh in on their experiences. > 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. Note that I'm explicitly advocating for us to keep the old hashes as long as is practical, avoiding any imposed pain on a "flag day." > 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. I'm not sure what tooling exists today to support this, but if it doesn't exist today it's conceptually easy to write. We'd have a 1:1 correspondence between hashes in the "legacy" and "ng" sets, and so it will be possible to perform an automatic migration without any human intervention. This assumes the data is identical in the "legacy" and "ng" git history, but if it's not we have larger problems. > 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. Good question! IMO it's premature to worry about the issues inherent in switching the source of truth (as it's currently not on the table). Personally, I'd prefer that we lose $FreeBSD$ altogether. For the way I interact with FreeBSD it causes grief more than solves any problem I have. > Anyway, don't take concerns I have for opposition to a switch, just > nerves that need to be quelled a bit first :) Not at all, this is one of the reasons I wanted to migrate this discussion to the freebsd-git list. It's something that can't be undertaken lightly. Any change needs to be planned, tested, and deployed with ample advance notice and opportunity for discussion beforehand.