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

[Sumit Garg]

On Wed, 3 Jan 2024 at 22:02, Tom Rini <trini at konsulko.com> 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.

Sure, as Tom pointed out below that we would shift to put subtree as
dts/upstream for v4. Does that make sense to you?

> >
> > 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.

Yeah we just need to modify the prefix as:

git subtree pull --prefix dts/upstream \
       git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
\
       <release-tag> --squash

> >
> > > +
> > > +    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>.

Sure, I will do that for v4.

>
> 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?

I am happy for you to do that. I am happy to assist in case any conflicts occur.

> 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?

IMO, we should give subtree a try and later if it becomes complex to
manage then we can switch to a custom script as well. It is
essentially a sub-directory which we start initially to manage via a
subtree approach but later we can switch to a custom script to sync
that subdirectory if there is a need.

-Sumit

>
> --
> Tom