From owner-freebsd-git@freebsd.org Thu Jun 18 17:39:27 2020 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 6079D35607B for ; Thu, 18 Jun 2020 17:39:27 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 49nq1q0NHMz3WJr; Thu, 18 Jun 2020 17:39:26 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f179.google.com with SMTP id h3so6571397ilh.13; Thu, 18 Jun 2020 10:39:26 -0700 (PDT) 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:content-transfer-encoding; bh=18VN2U68Nkp+OO7dTY/dVm6JqflHs5bruOyHW64v+Vc=; b=qeYsdcoOCSR79bPcn+QFgKRXdkCJPurEsYoJkF/DKSyJVMCFC3HX/uXAHPmjpr36yC FyQ+1guTEq4fuZxfB2pKopRAPOJDFr6/4GpiVVgmV9mH/W4pFcvMmpW+z7vTB23sBuPQ 1GxVaUQiDFnL6bCjieTqqvJjtmQE4m+U4oqueLIoTVJldK6tq1p5sorm80J30SUq+2Op 7auFsFHKxkI3JVUx1QXQDXWVr+aB5+VVTN3XayX7LblFQsSv7BV2yqT6pyOj+9DY1nYu su2gmiej8zjqUHuflpvtM2FasL65pkURxWB4Ae85EDI+UgJeesAx/NmpPq1ANOWEOp/X PmKA== X-Gm-Message-State: AOAM531Z4G+lXBzfCYVw8Mfv71ctnDfSy7XLyefXJLoE962REyEPQLrG 3+7CwVzFaChAQMkhdAGI/fWD+91gtP+YRyr2+ghmzywg X-Google-Smtp-Source: ABdhPJxwa5Ett2T1lG8DbcLnOK3SskhE3SIcmNfgr3RPZurZaG3xdrE57d1GsA/8fotNBySPuHG0DYGQLLvdZ/xt8yY= X-Received: by 2002:a92:de0d:: with SMTP id x13mr5384831ilm.256.1592501964888; Thu, 18 Jun 2020 10:39:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Thu, 18 Jun 2020 13:39:12 -0400 Message-ID: Subject: Re: Next odd commit affecting `git subtree split` experiments with contrib/elftoolchain To: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= Cc: freebsd-git@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49nq1q0NHMz3WJr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 18 Jun 2020 17:39:27 -0000 On Thu, 18 Jun 2020 at 04:44, Ulrich Sp=C3=B6rlein wrote: > > Yes, this is using plain git subtree w/o patches, but it's on a repo that= has no MFH > head =E2=86=92 project merges. As I wrote, it comes out with ~400 commits= , while a patched > subtree split will only produce about 280, so going with the patched subt= ree seems > more sensible. Indeed, but it's good to know that option 1 is also workable - this gives me more confidence in our ability to have a final version of the conversion within weeks/months. > However, I wonder if we cannot flatten the history to be a single line in= stead of the merges. > Do merge commits make any sense for the resulting repo? If we could make = it all linear, then > the "empty" commits would stand out better and filter-repo could toss the= m away. We can't make it entirely linear, because we do want to continue to represent upstream updates that went via the vendor branch happening concurrently with FreeBSD-local changes in contrib/, to support future updates. > The algorithm would be simple: > - for all merge commits, check their tree vs. the tree of all parents. > IFF one of the parents has the same tree as the merge commit > =E2=86=92 remove the merge commit I think this would work, but is not worth the effort, because this is an issue only for those maintaining some contrib/ software, and as long as there are a "reasonable" number of these extraneous commits they're easy to just ignore. > It might really be too bespoke for FreeBSD and we only need to do all of = this once, yes? Yes, I expect that we'll have to do this once (for each piece of contrib software) to bootstrap. I have seen other examples of projects with subtree-style updates not using git subtree though, so if there is a sufficiently general version it's worth upstreaming. >From git subtree's help: | If your subtree was originally imported using something other t= han | git subtree, its history may not match what git subtree is | expecting. In that case, you can specify the commit id t= hat | corresponds to the first revision of the subproject's history t= hat | was imported into your project, and git subtree will attempt to | build its history from there. However, having something upstreamable is not a requirement - I'm fine with a bespoke, even hacky solution, as we'll only need to use it once. (Option 2 is the patched git-subtree) > 2 would be my preference as well. So someone will need to run subtree spl= it > for all contrib software and let me know if there are blockers that the s= vn2git > conversion could help out with (or we need to help out all subtree splits= with a > dozen carefully placed grafts and a rewrite. Doesn't sound too bad?) I will try a few more contrib/ subtree splits individually, and later try running it on every one. Once we have appropriate documentation individual maintainers can test their subtrees.