Hi Junio, On Fri, 8 Mar 2019, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Sun, 3 Mar 2019, Junio C Hamano wrote: > > > >> "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> > >> writes: > >> > >> > Back when we stopped using MakeMaker, we forgot one reference... > >> > > >> > Johannes Schindelin (1): > >> > mingw: drop MakeMaker reference > >> > > >> > config.mak.uname | 1 - > >> > 1 file changed, 1 deletion(-) > >> > > >> > > >> > base-commit: 8104ec994ea3849a968b4667d072fedd1e688642 > >> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-146%2Fdscho%2Fno-perl-makemaker-v1 > >> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-146/dscho/no-perl-makemaker-v1 > >> > Pull-Request: https://github.com/gitgitgadget/git/pull/146 > >> > >> Good ;-) > >> Thanks. > > > > Gentle reminder that this has not made it into `pu` yet... > > Thanks. > > I'll try to make it a habit not to respond to 0/1 (but instead to > 1/1) as it is quite inefficient to get to 1/1 from 0/1 at least for > me X-<. Hehe. I do have something for you there: https://github.com/git-for-windows/build-extra/blob/master/apply-from-public-inbox.sh -- snip -- > Or perhaps GGG can learn to avoid 0/1 for a single-patch topic ;-) It is easier, and more consistent, to have a cover letter even then, for things like the broader explanation of the context, the changes since the previous iteration, and the range-diff (which would make v2, v3, v4, etc utterly unreadable from my point of view if they were integrated into the single patches, as I used to do with interdiffs). > Thanks anyway. Will try to apply directly on top of master. Thank you! While we're talking about "directly on top of master"... *after* it got some review, I would love to ask for the same favor for https://public-inbox.org/git/pull.160.git.gitgitgadget@xxxxxxxxx On the other hand, it is an old bug, I know, and it will break all CI builds for branches that are based off of older commits, anyway. I guess we'll need some sort of horrible hack in the git-sdk-64-minimal thing, to allow for patching this on the CI side, without adding commits to all of those branches. :-( So: I made up my mind, and that MSYS2 runtime v3.x patch does not need to be fast-tracked; it would not fix all the CI builds... Ciao, Dscho
