Jeff King <peff@xxxxxxxx> writes: > On Wed, Jan 03, 2018 at 02:42:51PM -0800, Isaac Shabtay wrote: > >> Indeed interesting... this one's for the books... >> Thanks for the patches. Any idea when these are going to make it to the >> official Git client builds? (specifically the Windows one) > > They haven't even been reviewed yet. If they get good feedback, then the > maintainer will pick them up, then merge them to 'next', and then > eventually to 'master', after which they'd become part of the next > major release. For a pure bug-fix, it may instead go to 'maint' and > become part of the next minor release. Even a pure bug-fix, unless it is something no longer needed on the 'master' front, goes thru 'pu'->'next'->'master' avenue first, and is recorded in the RelNotes with the notes like "(merge d45420c1c8 jk/abort-clone-with-existing-dest later to maint)" when it happens. side note: in fact "grep -e 'later to maint' RelNotes" is how I remind myself what to merge down to 'maint'; the actual procedure is a bit more involved (those interested in the details can find the 'ML' script on the 'todo' branch; its name stands for 'merge later') Later, after not hearing from people that the "fix" breaks things, the topic is also mreged to 'maint' and becomes part of the next minor release. > Right now we're entering release freeze for v2.16.0. We'd still take > fixes for recent breakages there, but given the age of the problem I > doubt it will make the cutoff. But as this is a bug-fix, it might make > it into v2.16.1. Yup. From the usual timeline, I'd expect this to be part of 'master' working towards 2.17 and to become a part of 2.16.x series. Thanks.
