Broken devicetree-rebasing history

Broken devicetree-rebasing history

[Hector Martin]

Hi Ian,

I just noticed that at some point in the devicetree-rebasing.git
history, a merge sneaked in that linked in the mainline git history.
That unfortunately somewhat defeats the purpose of the repo, since you
can't clone it without cloning all of Linux now.

The last good tag is v5.9-rc2-dts; v5.9-rc3-dts is the first one to
include the bad merge. With -rc2 you get a 128MB clone; -rc3 ends up
pulling in 1GB+ from the rest of Linux.

I thought of giving a shot at fixing it myself, but it seems the filter
state/etc branches aren't available on the kernel.org repo, so AIUI
re-bootstrapping the filtering process would require filtering the
entire kernel history again, not just the changes since the bad merge...

For the Asahi Linux project (Linux on the new Apple machines) we're
looking into having a dedicated DT repo where we can stage our bleeding
edge changes before they are merged, since we want that to build our
bootloader+DT packages without pulling in the entire kernel, and I was
thinking of reusing the devicetree-rebasing infra and throwing up a
cronjob that repeatedly rebases our latest changes from our kernel repo
on top of whatever is the latest version in devicetree-rebasing.git...

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub

Re: Broken devicetree-rebasing history

[Ian Campbell]

Thanks for the heads up, I'll (hopefully) take a look over the weekend.

FYI the state stuff can be found in
https://github.com/ijc/devicetree-conversion-state-v2

Ian.

On Fri, 2022-03-11 at 17:58 +0900, Hector Martin wrote:
> Hi Ian,
> 
> I just noticed that at some point in the devicetree-rebasing.git
> history, a merge sneaked in that linked in the mainline git history.
> That unfortunately somewhat defeats the purpose of the repo, since
> you
> can't clone it without cloning all of Linux now.
> 
> The last good tag is v5.9-rc2-dts; v5.9-rc3-dts is the first one to
> include the bad merge. With -rc2 you get a 128MB clone; -rc3 ends up
> pulling in 1GB+ from the rest of Linux.
> 
> I thought of giving a shot at fixing it myself, but it seems the
> filter
> state/etc branches aren't available on the kernel.org repo, so AIUI
> re-bootstrapping the filtering process would require filtering the
> entire kernel history again, not just the changes since the bad
> merge...
> 
> For the Asahi Linux project (Linux on the new Apple machines) we're
> looking into having a dedicated DT repo where we can stage our
> bleeding
> edge changes before they are merged, since we want that to build our
> bootloader+DT packages without pulling in the entire kernel, and I
> was
> thinking of reusing the devicetree-rebasing infra and throwing up a
> cronjob that repeatedly rebases our latest changes from our kernel
> repo
> on top of whatever is the latest version in devicetree-
> rebasing.git...
> 

Re: Broken devicetree-rebasing history

[Ian Campbell]

On Fri, 2022-03-11 at 09:01 +0000, Ian Campbell wrote:
> Thanks for the heads up, I'll (hopefully) take a look over the
> weekend.

My first attempt at rerunning the conversion still had the problem (I
think I didn't wind the state branch back far enough). A second one is
running now and looks to have avoided the issue. I think it'll finish
later on today but I may not have a chance to check and push the
results until later in the week.

Obviously this is going to involve a force push and a whole new pile of
updated tags in the repo on kernel.org, I'll send an heads up to the
list when I get as far as actually pushing.

FYI the new mirror will be
https://github.com/ijc/devicetree-rebasing-v3 and the new state repo
will be https://github.com/ijc/devicetree-conversion-state-v3. The old
state repo will remain frozen.

Cheers,
Ian.

Re: Broken devicetree-rebasing history

[Ian Campbell]

On Sun, 2022-03-13 at 12:00 +0000, Ian Campbell wrote:
> 
> Obviously this is going to involve a force push and a whole new pile of
> updated tags in the repo on kernel.org, I'll send an heads up to the
> list when I get as far as actually pushing.

Done.

Thanks again for the heads up.

Cheers,
Ian.