Stefan Beller <sbeller@xxxxxxxxxx> writes: >> Speaking of what to and not to include in the upcoming release, we >> do want to include Stefan's off-by-one fix to the submodule-helper, >> but that is blocked on Windows end due to the test. > > I'd be happy either way, i.e. we could revert that fix and make a release? > AFAICT, Windows only has broken tests, not broken functionality with that > submodule bug fix. If you are referring the "trailing /. should not make difference when resolving ../relative/path" change with "rever that fix", I think that may be a reasonable way to proceed. Even though that change is a bugfix (at least from the point of view by me and j6t in the recent discussion), it is a behaviour change that we would want to see feedback from existing submodule users and deserves a longer gestation period. And that part is not yet in 'next' yet ;-) > If we want a longer gestation period, we'd ideally merge it to master > just after a release, such that we "cook" it in master without having > it in any release (we had a similar discussion for the diff heuristics IIRC). Yes. It would mean that we would need a separate patch that adds the !MINGW prerequisite to some tests to what is on 'next', as the early patches on sb/submodule-ignore-trailing-slash~ that fixes off-by-one is the right thing to do either way. It of course needs help from Windows folks to validate the results.