Next odd commit affecting `git subtree split` experiments with contrib/elftoolchain

Ed Maste emaste at
Thu Jun 18 17:39:27 UTC 2020

On Thu, 18 Jun 2020 at 04:44, Ulrich Spörlein <uqs at> wrote:
> Yes, this is using plain git subtree w/o patches, but it's on a repo that has no MFH
> head → 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 subtree 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 instead 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 them 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

> 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
>     → 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 than
|           git subtree, its history may not match what git subtree is
|           expecting. In that case, you can specify the commit id <onto> that
|           corresponds to the first revision of the subproject's history that
|           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

(Option 2 is the patched git-subtree)
> 2 would be my preference as well. So someone will need to run subtree split
> for all contrib software and let me know if there are blockers that the svn2git
> 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.

More information about the freebsd-git mailing list