From owner-freebsd-git@freebsd.org Wed Feb 22 14:53:43 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 5F3ADCE917E for ; Wed, 22 Feb 2017 14:53:43 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 27BC31923; Wed, 22 Feb 2017 14:53:43 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by mail-it0-x241.google.com with SMTP id w185so514120ita.3; Wed, 22 Feb 2017 06:53:43 -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=58E2YVcYSSWMVfOB+nxM/zIsB5K8+tmK42m7GuA0fZw=; b=pMP2GO+n3+V6Q2qIfRZ/ed4FwAqa/6O0jgkZAP2Ir+aOBYYfUPHz8z2fUsNmAUChQ2 htst5m4yVpHG6vNwwkgUfUfCGbc/cwPErlzraDG92boN4yeKa7ZodlAoo7amiZTfYN55 QmMGRZUFaxT+btGw2/Qi2xmjP5N2lwDWhwkYfoVZ5PX+arWVt52ahzMncfBxCczQJKxA Btsfv50qCOSnftEeM/XfEBpL6MBOggN2gZb6LTH6u4NSlkn3dIjQvjuImoIlVWMtHBvD teDst2HyL9ZfLTCJ6SGIuiGygHZF+BPaa5FZ0jQcl22Lme+GfxmN6GqEvqKOA5VOyqCs VnOA== 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=58E2YVcYSSWMVfOB+nxM/zIsB5K8+tmK42m7GuA0fZw=; b=GNdTSRD/4E7K6rbvdPlzaNw3rdwrGEdZEjKB3h1DshxBFewFwF51ChMniKo5aamC6T pSshNN10wiFLMji7Mk89YbVX1F/JIgrGERG9Emr/vmJH6e8NpP121YLeUO0DZqNGGD3O uGKsIKb6lnS5cj2zniQXt/oLE2Vq3N9KqHdgdEb8neUvPS1x14BMW6Q+6ZSpchaE9qgd /HAwvbEQsakHV4jjItqGV6tXTLOfVYtkLFpXgipJEjqhqMibvRLaBw+tJvq0aOqVLwJF a+gq5NWg39Fs3KV9X6YxForAdEFnfqcWYuDqei/PUjWM1KEDCF8JmdKi1Y20tzYD4lqD +Fxw== X-Gm-Message-State: AMke39mlkEWmhUc3tCnmfIlS+V0DwGwEMRcoVE+/zhIlBfOCG7eceaG/joqUy1Sl7DPfGGZAbHff6RR4va7I6g== X-Received: by 10.36.28.85 with SMTP id c82mr2209635itc.49.1487775221469; Wed, 22 Feb 2017 06:53:41 -0800 (PST) MIME-Version: 1.0 Sender: uspoerlein@gmail.com Received: by 10.107.132.83 with HTTP; Wed, 22 Feb 2017 06:53:40 -0800 (PST) In-Reply-To: References: <49da18e4-b211-c48d-5486-368cda912fc0@multiplay.co.uk> <86mvdfy3qs.fsf@desk.des.no> From: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Date: Wed, 22 Feb 2017 15:53:40 +0100 X-Google-Sender-Auth: b2rsS4t-vNDkH5Qz1fwKPfx2Lnc Message-ID: Subject: Re: Reconsider switching from svn to git? To: Warner Losh Cc: Ed Maste , freebsd-git@freebsd.org 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 14:53:43 -0000 2017-02-22 0:47 GMT+01:00 Warner Losh : > On Tue, Feb 21, 2017 at 1:22 PM, Ed Maste wrote: >>> 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. Zero pain, really. If I give you the commit hashes of broken-repo and new-repo at the same state you can instruct git to merge these two commits, preferring the tree of whichever side. You can then continue to pull/merge from the new-repo's master. There's probably a magic three-line incantation required, but really it's no biggy (albeit annoying). If even that surgery is too much, you can also export a complete diff of your-branch to origin/master in the old repo, and that would apply w/o conflicts to new-repo, as long as you sync them both to the same tree-object (which they would have, as the problem is only in the metadata). >> 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 Before doing any re-roll of the repository, it would be nice if we could actually restore the CVS part of the history that got brutally mangled with the cvs2svn conversion. Or, we say fuck it, and only convert the SVN history (starting 2008) and tell people to use graft-points into https://github.com/dspinellis/unix-history-repo/ if they are interested in what "git blame" produces. > > 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. "Nice property"? If there was something I could kill it would be this. Have you ever migrated a system from stable/9 to stable/10 and then dealt with all the mergemaster fallout because the frigging IDs change w/o any content changes? That is a totally useless feature. I would much prefer we had CVS IDs back, so that you could at least see how many revisions there were to the file in between. > > Anyway, don't take concerns I have for opposition to a switch, just > nerves that need to be quelled a bit first :) > > Warner