On Sat, Dec 17, 2022 at 12:26 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Karthik Nayak <karthik.188@xxxxxxxxx> 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. Right! I think I just have a habit of rebasing on top of master on a general basis. I'll keep the old base and modify my tags to make sure the next range-diff will use `2e71cbbddd` as the base for both ranges. -- - Karthik
