Date: Thu, 14 Nov 2019 17:20:04 -0700 From: Warner Losh <imp@bsdimp.com> To: Xin LI <delphij@gmail.com> Cc: Ilya Bakulin <ilya@bakulin.de>, freebsd-git@freebsd.org Subject: Re: FYI - LLVM migration to Git and GitHub has started Message-ID: <CANCZdfr-RS6Xk_HQ=eWugG7YV0Ame8UipKH_xqPmYxu9E_%2BFTw@mail.gmail.com> In-Reply-To: <CAGMYy3tZcUE%2B43gA9M=FUkgX25hN7NnViruiXej7woQZF6Jm3g@mail.gmail.com> References: <CAPyFy2Aaovca5B0D0cyo3r0%2B7%2BS4CK%2BnhmfuY4V1fLmjvJ49dQ@mail.gmail.com> <CADzbx%2BqQrXrzvOS=Rpww7NmW4xosmDc8HA%2B-ML8JxfFtPXG6%2BQ@mail.gmail.com> <CANCZdfofA%2B_utwE84qs5fUhQyxJxNYENZc=pQnShb3%2B8MppBFg@mail.gmail.com> <CAGMYy3tZcUE%2B43gA9M=FUkgX25hN7NnViruiXej7woQZF6Jm3g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 14, 2019 at 12:39 PM Xin LI <delphij@gmail.com> wrote: > > On Wed, Nov 13, 2019 at 10:29 AM Warner Losh <imp@bsdimp.com> wrote: > >> Vendor branches break. >> > > Speaking for this, I have took contrib/file as an opportunity to try out > how git merge works in FreeBSD's context (without using submodules). > Basically we would have the github.com/file/file histories stashed into > one branch, and perform two merges. > > The first one would "bootstrap" the history, by performing a git merge > with -s ours of the previously merged tag. This would require some > cleanups: the upstream's CVS exporter was broken and some RCS IDs were not > correctly updated, so technically one would have to patch the contrib/file > tree to bring the git's vision of RCS IDs, then perform a merge -X subtree > merge. > > The second one would be the actual merge (-X subtree=contrib/file). > Future imports would only need this merge. > > If the upstream was not using git, these could be pushed to a different > branch to hold it (which is pretty much what we do in subversion in its > flattened namespace under vendor/foo/dist). > Do you have the results of this published somewhere? In looking into submodules, I couldn't figure out how to layer changes on top of the submodule in any way that was approaching sane... If we used the code verbatim, as is in the upstream repo, it might be OK, but it looks like it's intended to solve different problems than our 'vendor branch' issue. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr-RS6Xk_HQ=eWugG7YV0Ame8UipKH_xqPmYxu9E_%2BFTw>