Strange commit

[Warner Losh]

On Wed, Mar 25, 2020, 8:36 PM Ed Maste <emaste at freebsd.org> wrote:

> On Wed, 25 Mar 2020 at 22:06, Warner Losh <imp at bsdimp.com> wrote:
> >
> > On Wed, Mar 25, 2020, 1:33 PM Ed Maste <emaste at freebsd.org> wrote:
> >>
> >> On Wed, 11 Mar 2020 at 05:20, Ulrich Spörlein <uspoerlein at gmail.com>
> wrote:
> >> >
> >> > This is intentional, please see
> https://github.com/freebsd/svn2git/blob/1a0b3e0230e1b2430e5d8eb91ac99aeff5a1614d/src/svn.cpp#L883
> >> >
> >> > Only projects and user branches are represented as merges to master,
> as they usually have a full tree. This seemed to match the git model better
> (as opposed to the SVN model).
> >>
> >> IMO we do want vendor code updates recorded as merges. This is already
> >> happening today for certain updates (svn merge -c <rev> updates I
> >> believe). For example my most recent ELF Tool Chain vendor update:
> >>
> https://github.com/freebsd/freebsd/commit/ca8624403626d5a4e13f5006026ca6ba40c12ac5
> >
> > How do we both do subtree to not not have the vendor repos commingled
> inbour tree and do this?
>
> I'm not sure I understand what you mean here, but there's no problem
> for us to have the original snapshotted history just as we do with
> merges from svn vendor branches today.
>

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
subtree 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.

Warner

>