[Development] Merging qtquickcontrols2 into qtdeclarative

Michal Klocek michal.klocek at qt.io
Tue Jul 13 15:33:18 CEST 2021


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.)
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20210713/5c8231d9/attachment.html>


More information about the Development mailing list