On Tue, 13 Jul 2021 at 21:38, Michal Klocek <[email protected]> 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 <[email protected]> on behalf of Elvis
> Stansvik <[email protected]>
> Sent: Tuesday, 13 July 2021 13:23
> To: Qt development mailing list <[email protected]>
> Subject: Re: [Development] Merging qtquickcontrols2 into qtdeclarative
>
> Den tis 13 juli 2021 kl 10:45 skrev Oswald Buddenhagen
> <[email protected]>:
> >
> > >On 12 Jul 2021, at 21:19, Thiago Macieira <[email protected]>
> > >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
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
