[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNARhah+P+wESAYxVUzRkD81EacR_J+muDcP7HLZpCRkd8g@mail.gmail.com>
Date: Sat, 16 Dec 2023 02:02:30 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Leonardo Bras <leobras@...hat.com>
Cc: Christoph Hellwig <hch@...radead.org>, Randy Dunlap <rdunlap@...radead.org>,
Nicolas Schier <nicolas@...sle.eu>, Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>, Mauro Carvalho Chehab <mchehab@...nel.org>,
linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [RFC PATCH v5 1/1] scripts: Introduce a default git.orderFile
On Wed, Dec 13, 2023 at 2:10 AM Leonardo Bras <leobras@...hat.com> wrote:
>
> On Tue, Dec 12, 2023 at 05:08:34AM -0800, Christoph Hellwig wrote:
> > On Tue, Dec 12, 2023 at 05:09:21PM +0900, Masahiro Yamada wrote:
> > > Unlike .gitignore, this feature is opt-in rather than enforced.
> > >
> > > To use this, you need to run
> > >
> > > 'git config diff.orderFile scripts/git.orderFile'
> > >
> > > or
> > >
> > > 'git diff -C scripts/git.orderFile'
> >
> > Oh, ok. That greatly reduces my concern.
>
> Yes, it's an opt-in, so no user should be directly impacted.
Applied to linux-kbuild.
Thanks.
> >
> > >
> > > Indeed, the file order is subjective, leaving
> > > us a question "do we need it in upstream"?
>
> The main idea is patch generation.
> This file's order is supposed to be the best order for reading a raw patch
> and understanding the code changes.
>
> > >
> > > At least, it is harmless for people who have no interest.
> >
> > .. but this is still a good question. I'm not really sure there is
> > much of a need for it, but as long as it doesn't harm everyone else
> > I'm at least neutral on it.
>
> diff.orderfile was introduced in git to help order the git diff, and thus
> the patch generation, in a way that it's easier to understand what the
> commit / patch intends on doing.
>
> Take this example introducing a feature foo, you should see:
> - Documentation on foo, if introduced
> - How is foo enabled in build system, if needed
> - The types / stucts / fields introduced by foo, if any
> - The interface for using foo, if any
> - The actual foo implementation.
>
> Of course the actual order is open to discussion, and I encourage everyone
> to suggest any other items or order.
>
> Thanks!
> Leo
>
>
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists