From owner-freebsd-git@freebsd.org Wed Sep 25 19:50:11 2019 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 93EF7130C7A for ; Wed, 25 Sep 2019 19:50:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46dpYt6571z4Nxq for ; Wed, 25 Sep 2019 19:50:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x844.google.com with SMTP id c3so789674qtv.10 for ; Wed, 25 Sep 2019 12:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CzblJQszxNRaHvys/vowcH8zRg35FAhUSV7Ui/wwIaE=; b=rmioObAtcCjv8zd97Ndf3xCuz8DhcMKgK+pZkqOkY5FpfhLqfGwHntrH2BNdJ0YLtA lTQzlPumpW+whbyzljLsyokB0A3If7Bu0U9OQ1bj+yxbeugCla9CnPOAYXkamVrY45rX vb7tA++8sG9ApzlQLcL+cdYnn69MK/egI6qsfZ8xL7wFhotS+KLbV68R9O3gVqyGqTEb zISIkEg+N78z1kv33yiFigbqlIX/I+D+jpUXeW2bk7BHEKPhXcsphZuvC8RxsnUknCni IwTyKFl56mk2cK/shUNWOQMe6JUP6WJsr7hTp4Wa0y+UTe8nCRgGh1CTl2FC9bNkHfxM N73w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CzblJQszxNRaHvys/vowcH8zRg35FAhUSV7Ui/wwIaE=; b=pvRCDVqnEk2JqkRDInGhn7AfAApTGjHCPIYIC70Txv3E9w2qKLPhWYsre5cGSfMFa9 9XKCU/AhbF+3CDTKsceoBszYteUhzQ3vPXXA0WbvDGX/NZ3SyvmvSrWIXKQHvw9QmGAb NwOA+pDUF/KtiDk18ijFjtPF8tpfGj8koBt7mU4rKO0e/wG83TQJK4r5rpjdl3Tejpsd FKHuwB1O1otNas4ezpExGAvx6AOTQsJyaJeW9FXR2BahVtRsPuLTVbcrd9DejPjnAGGJ MUXU3TSliJZZbXzXMBjkKu+WMCvQnFKnwylTwY1dMUTiLSYCDZnXGFawe70mS0MbfW4B aPUA== X-Gm-Message-State: APjAAAVZoKIy2JsKzVzeuCluYORRCH7vxCPi6MnIbSwh+7wqyDZel418 s/A+fNR5Mn5KyanwH87U/jJtv3oObZCxBtYmgOzuHg== X-Google-Smtp-Source: APXvYqwNoo1iHNpQqVm3GCq2BOjsXzdEpmSWg4Mj2PNazHPZl+6tSV6crKQHVBihgLzpeveax72+eiIKQpNtG9PnE1A= X-Received: by 2002:a05:6214:70c:: with SMTP id b12mr1138807qvz.87.1569441009431; Wed, 25 Sep 2019 12:50:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 25 Sep 2019 13:49:58 -0600 Message-ID: Subject: Re: Service disruption: git converter currently down To: Ed Maste Cc: Sean Chittenden , freebsd-git@freebsd.org, =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= X-Rspamd-Queue-Id: 46dpYt6571z4Nxq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=rmioObAt; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::844) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.45 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-git@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[4.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.46)[ip: (2.56), ipnet: 2607:f8b0::/32(-2.61), asn: 15169(-2.18), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.29 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, 25 Sep 2019 19:50:11 -0000 On Wed, Sep 25, 2019 at 11:56 AM Ed Maste wrote: > On Wed, 25 Sep 2019 at 10:53, Warner Losh wrote: > > > > But this really was a merge from stable/10 into master, > > I think this is just a question of semantics, not VCS details - I > would argue that it is not a merge in the ordinary sense of the word, > and is certainly not a merge in the git sense. You're right that this > should be represented in history as if it were a cherry pick. Bogusly > adding over 9000 commits to the history is definitely not the "least > wrong" thing the conversion could do. > git log always requires added care. There's not actually 9000 commits there. The tree looks fine topologically. Its purely an artifact of git log. > git log --first-parent isn't really a solution here either, because > there are cases where one legitimately does want history from both > parents, especially working in downstream projects. > I'm pretty sure it would be fine, even in that case. > > I'd offer the opinion that needing to know about things like git log > --first-parent vs having to rebase every single downstream fork, > > We won't need to rebase every fork - in no case should the path > forward be worse than uqs's suggestion of a merge from both old/new > conversions. > IMHO, uqs suggestion is a complete non-starter, at least the "git diff | git patch" one. It destroys all local history, commit messages, etc. Except for the most trivial cases, it's not really going to fly with our users. His other, followup ones might be workable into scripts. I'm not sure you can merge, as there's no common ancestor that's recent enough to give it a chance at succeeding (since the different exports would have different hashes starting fairly early in our history). My experience with qemu is that long-lived merge-updated branches become quite difficult to cope with after a while. It took me three weeks to sort out that relatively simple repo. A rebase has a chance of working for people following a 'rebase' work flow. I can write the scripts to do that because I basically already have them and they just need to be modified to do a 'onto' for the easy to write, but slightly risky case of rebasing them across the chasm to a new point on master (as opposed to rebasing them to the same point on master). The latter is possible, just needs a bit more scripting and wouldn't be too bad to write and the least risky way to update across the chasm for people that don't want to (or can't due to conflicts) jump in the easy but risky way. However, for people like CHERIBSD who follow a 'merge from upstream' model which never rebases (since that would be anti-social to their down streams), I'm having trouble understanding how that could work. At work, we basically do the merge from upstream with collapse model, which I'm having trouble seeing how to move from old hashes to new. I'd like to know what the plan for that would be and would happily test any solution there with a copy of our repo. I'd even be happy to run experiments in advance of there being something more public available to see what options do or don't work. Warner