Strange commit

Warner Losh imp at
Fri Mar 27 21:06:50 UTC 2020

On Fri, Mar 27, 2020, 1:30 PM Ed Maste <emaste at> wrote:

> On Fri, 27 Mar 2020 at 15:12, Warner Losh <imp at> wrote:
> >
> > The vendor repos we wanted to do would be complete on their own. We
> don't want the revisions of those repos in the main repo. A merge commit
> would make us have them in the main repo. Then again, maybe this eliminates
> subt free if we can't do that. It was why we were looking at the other one:
> it creates a repo that is independent of the merged in repo and it requires
> no extra modules for our users to install.
> We do want revisions of the contrib code in the main repo, otherwise
> we lose the history and the ability to easily maintain our local
> changes.

I'm sorry, that's a *HUGE* change from what we decided. And it doesn't lose
the ability for us to maintain our own local changes easily...

We decided, specifically that we'd export the vendor branches, vis git
subtree, to their own repos that would live under our github. We'd then use
git subrepo to them pull in the changes into src/contrib, et al, as a
single commit with tracking information. This would keep us from being the
union of all possible upstream repos (think llvm). We'd have sufficient
tracking info to know the history, but it might be a little awkward to pull
it all out since you'd need to download the extra repo and install git
subrepo. In that scenario, they most definitely aren't merge commits in the
classic sense (logically they are, and subrepo records enough details... we
thought subtree might also do it too, but that was a point that was
supposed to be investigated, but I'm not sure if that detail has been). We
were also, IIRC (and I may not), going to bootstrap the vendor branches so
any of them could be used to update from the get-go in the new git repo so
we wouldn't need the 'vendor branch collapsing' stuff from svn, because
we'd have already done it in svn prior to the export and because the
exported repos would be sufficient.

Maybe we should chat about this stuff again, but I have a very very clear
memory of all of this, and thought it was a good plan despite some initial



More information about the freebsd-git mailing list