[PATCH v3 5/8] doc: devicetree: Updates for devicetree-rebasing subtree

[Sumit Garg]

Hi Michal,

On Thu, 4 Jan 2024 at 15:39, Michal Simek <michal.simek at amd.com> wrote:
>
>
>
> On 1/3/24 17:32, Tom Rini wrote:
> > On Wed, Jan 03, 2024 at 09:19:40AM -0700, Rob Herring wrote:
> >> On Thu, Dec 28, 2023 at 4:59 AM Sumit Garg <sumit.garg at linaro.org> wrote:
> > [snip]
> >>> +In order to maintain devicetree files sync, U-Boot maintains a Git subtree for
> >>> +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly
> >>> +kept updated with every new kernel major release via subtree pull as follows::
> >>
> >> I would suggest dropping "-rebasing" in the u-boot tree. (I wish we
> >> had in the original repo). I don't think it's relevant.
> >>
> >> We're not likely to regenerate the tree, but any clue what 'git
> >> subtree pull' would do in this case? It could happen if we switched to
> >> git-filter-repo.
> >>
> >>> +
> >>> +    git subtree pull --prefix devicetree-rebasing \
> >>> +        git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \
> >>> +        <release-tag> --squash
> >>
> >> I'd put this in a script to run. Documentation tends to be not quite
> >> correct. A script could also be smarter and figure out <release-tag>.
> >
> > Since you had mentioned elsewhere moving the kernel scripts/dtc/ to
> > something using subtree, I do hope to learn some lessons from what you
> > do there. The first thing is that given the size/nature of the commits,
> > I had figured I'd be the one doing this as a subtree pull+squash then
> > push, rather than posting to the ML since it'll be huge and
> > un-reviewable, but with a note sent off to the ML that people should be
> > aware the next sync has been done and retest as needed. But Sumit, were
> > you planning to do some of this instead?  The second thing is that if we
> > move the subtree part in to dts/ instead (where we will still have the
> > Makefile/Kconfig we have today and then our Makefiles within the
> > directories, this might get more complex and so really require a script
> > to keep it from getting error prone?
>
> I played with this series and didn't really have time to dig into subtree
> mechanics but one thing I see is that when squash and merge happens you can't do
> simple rebase anymore which is time to time very useful.
> I see some different rebase strategies and --rebase-merges option but if this is
> adopted it should be properly described how to rebase u-boot tree which contains
> some subtrees.

Did you observe any specific difference with respect to subtree merge
commits (Tom will likely do those in the beginning of next release
cycle) when compared with normal merge commits when Tom pulls in code
from different custodians like one example below? The same rebasing
rules should apply to both types of merge commits.

commit dffa6d0210f57793f1e4e1e209d91ca5642e4d05 (origin/next)
Merge: 2b28c3b871c e266d273114
Author: Tom Rini <trini at konsulko.com>
Date:   Mon Jan 1 12:38:15 2024 -0500

    Merge tag 'dm-next-1124' of
https://source.denx.de/u-boot/custodians/u-boot-dm into next

    support propagating supernode properties with bootph schema
    align bloblist with v0.9 of Firmware Handoff spec

-Sumit

>
> Thanks,
> Michal