[Development] Merging qtquickcontrols2 into qtdeclarative

[Sze Howe Koh]

On Tue, 13 Jul 2021 at 21:38, Michal Klocek <michal.klocek at qt.io> wrote:
>
> Hi
>
> Please note qtpdf repository was merged into qtwebengine, authors wanted to keep all the history so it was kept and git blame works nicely. However, qtwebengine git repo is anyway big in size so adding extra ~100 commits did not have much impact.
>
> https://codereview.qt-project.org/c/qt/qtwebengine/+/270649
>
> Br
>
> Michal
> ________________________________
> From: Development <development-bounces at qt-project.org> on behalf of Elvis Stansvik <elvstone at gmail.com>
> Sent: Tuesday, 13 July 2021 13:23
> To: Qt development mailing list <development at qt-project.org>
> Subject: Re: [Development] Merging qtquickcontrols2 into qtdeclarative
>
> Den tis 13 juli 2021 kl 10:45 skrev Oswald Buddenhagen
> <oswald.buddenhagen at gmx.de>:
> >
> > >On 12 Jul 2021, at 21:19, Thiago Macieira <thiago.macieira at intel.com>
> > >wrote:
> > >> So a full history import MAY have negligible marginal impact over a
> > >> squashed import (.git is compressed).
> > >
> > that might be the case.
> >
> > but the point remains that the history that didn't exist along the
> > merged mainline would live elsewhere (unless we'd import all branches
> > and tags as well - we actually did that in qt creator, and it looks
> > kinda weird and confusing).
> >
> > On Mon, Jul 12, 2021 at 11:22:54PM +0200, Elvis Stansvik wrote:
> > >Personally I'm always frustrated when I hit a dead end during git
> > >blame.
> >
> > >Even if the original repo will be kept around, it's an added
> > >obstacle.
> > >
> > a rather small obstacle, given that we have a git-qt-grafts script that
> > pretty much completely automates the process (it would actually need a
> > bit of a revamp by now).
>
> Yea, I just thought it a good idea to follow Thiago's suggestion to
> see what the cost would be to do a full history import. But I may have
> misunderstood what is even possible and not.
>
> As an outsider doing a sort of drive-by git blame trying to find the
> rationale for something, I may not know about special tooling that Qt
> has.
>
> But yes, you folks who work day to day on Qt should decide. Just
> wanted to chime in with my opinion.
>
> >
> > >And at some point, I'm sure it will no longer be available.
> > >
> > we keep around all repos. the remote may just need an adjustment to
> > point to {graveyard}/.
>
> Alright, that's good. In the project I was digging through the other
> week, the commit that added the code didn't even say where it came
> from, just something like "Code moved from old repo", and after
> extensive searching I concluded that "old repo" was no longer online.
>
> Qt being a more serious project, I'm sure you guys will leave a better
> commit message and won't start bulldozing over your {graveyard}/ :)
>
> Elvis
>
> >
> > (speaking of which, it might be actually time to do that with qt.git,
> > rather than only renaming it.)

I tried this on my local repo and there were surprisingly few
conflicts (most were in dist/changes-*).

    cd qtdeclarative
    git checkout dev
    git remote add -f qqc2 ../qtquickcontrols2
    git merge --allow-unrelated-histories qqc2/dev

If we prepare qtquickcontrols2.git beforehand (for example, by moving
dist/ into a subdirectory), the conflicts would be reduced. The
labour-intensive part is then merging the CMakeLists and testing.

If I understood the earlier talk about "grafting" correctly, it can
avoid the history duplication that occurs with my approach above.
However, I don't know how to achieve that -- Could someone kindly post
a sequence of commands?


Regards,
Sze-Howe