Re: [PATCH v3 0/2] check-attr: add support to work with revisions

>
> Karthik Nayak <karthik.188@gmail.com> writes:
>
> > Changes since version 2:
> > - Changes to the commit message [1/2] to use more specific terms and to
> >   be more descriptive.
> > - Moved the flag's position in the documentation to be before the unbound
> >   list of non-options.
> >
> > Range-diff against v2:
> >
> > 1:  2e71cbbddd < -:  ---------- Git 2.39-rc2
> > -:  ---------- > 1:  57e2c6ebbe Start the 2.40 cycle
>
> Does this new iteration use something that was added between these
> two bases?  Asking because the choice of new base is questionable.
> I would understand it if the rebase were on top of v2.39.0 tag,
> though.
>
>  * If the updated series depends on new APIs and features added
>    since the old base, do rebase on the new one to take advantage of
>    them.
>
>  * A bugfix patch series may want to avoid using the newest and
>    greatest if it allows the series to be applied to the older
>    maintenance track, and keeping the older base may make more
>    sense.
>
>  * If a series based on an older base no longer merges cleanly to
>    'master' and/or 'next', but rebasing on a newer base makes it
>    merge cleanly, do rebase.
>
>  * Otherwise, keeping the same base is preferred.
>
> When rebasing is appropriate, choosing a well-known base (e.g. a
> tagged release) helps others.