Junio C Hamano <gitster@xxxxxxxxx> writes: > "Linus Arver via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> +There is one guiding principle for choosing the right starting point: in >> +general, always base your work on the oldest integration branch that >> +your change is relevant to (see "Merge upwards" in >> +linkgit:gitworkflows[7]). What this principle means is that for the >> +vast majority of cases, the starting point for new work should be the >> +latest HEAD commit of `maint` or `master` based on the following cases: >> + >> +* If you are fixing bugs in the released version, use `maint` as the >> + starting point (which may mean you have to fix things without using >> + new API features on the cutting edge that recently appeared in >> + `master` but were not available in the released version). > > I think this is technically not optimal, but is good enough for the > sake of simplicity and brevity[*]. > > [Footnote] > > * An very old but still severe bug in tagged versions would want to > be fixed ideally not on top of 'maint' but on top of the latest > tagged version in the same maintenance track. E.g. if the commit > X introduced the bug, you may ask "git describe --contains X" the > oldest version the commit appears in, say "v2.30.0-rc2-gXXXXXX". > Then you would run "git checkout -b fix v2.30.9" to start the > branch to fix it. In this example, are we using v2.30.9 as a starting point, not v2.30.0 because v2.30.9 is the latest tagged version that is in 'maint'? I think this nugget of knowledge should be included in a v3 of this series. Will update. >> +* Otherwise (such as if you are adding new features) use `master`. >> + >> +This also means that `next` or `seen` are inappropriate starting points >> +for your work, if you want your work to have a realistic chance of >> +graduating to `master`. They are simply not designed to provide a >> +stable base for new work, because they are (by design) frequently >> +re-integrated with incoming patches on the mailing list and force-pushed >> +to replace previous versions of these branches. > > "unstable" is not the primary reason why you shouldn't build on > 'next'. It is "your work, if queued on 'next', cannot be merged to > 'master' without pulling all the other undercooked stuff still in > 'next'", as you describe in the next paragraph. But that is > different from being unstable. I'd suggest to use something like > this instead: > > ... not designed to be used as a base for new work---they > are there only to make sure that topics in flight work well > together. A topic that is literally built on top of 'next' > cannot be merged to 'master' without dragging all the other > topics in 'next', some of which may not be ready. In > addition, `seen` is frequently re-integrated with incoming > patches ... Will update. Thanks.
