Date: Thu, 18 Jun 2020 13:39:12 -0400 From: Ed Maste <emaste@freebsd.org> To: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= <uqs@freebsd.org> Cc: freebsd-git@freebsd.org Subject: Re: Next odd commit affecting `git subtree split` experiments with contrib/elftoolchain Message-ID: <CAPyFy2D0uKboet14y=%2BcEmFL6xt14p8nCqysDwmHYzyMLFd-Fw@mail.gmail.com> In-Reply-To: <CAJ9axoTpyjpv9FbGL9s6ij9N7fZjkJHUSkxnpQJUPoT96c0tBg@mail.gmail.com> References: <CAPyFy2DR6R4S7kgkRtrWzPBuD_6QR=A_hU=sP%2BLm==Y61AKhsA@mail.gmail.com> <CAPyFy2BLM4=n4gbmfy19Vbo4c7c1JUYhB6MDTsJeU%2BLMEsfEmw@mail.gmail.com> <CAJ9axoS-VSQm%2B8_NLYJ%2BvURmH2CDteYMYHsFbf%2BCfyDjCcCPdw@mail.gmail.com> <CAPyFy2C2z_rB%2B8oxR3ajacmu3kkrsieiispD4ms67VKq7HE%2B=Q@mail.gmail.com> <CAJ9axoTpyjpv9FbGL9s6ij9N7fZjkJHUSkxnpQJUPoT96c0tBg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 18 Jun 2020 at 04:44, Ulrich Sp=C3=B6rlein <uqs@freebsd.org> 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 <onto> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2D0uKboet14y=%2BcEmFL6xt14p8nCqysDwmHYzyMLFd-Fw>