Re: [PATCH v5 00/27] Prepare the sequencer for the upcoming rebase -i patches

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 24, 2016, 20:16 UTC
Message-ID: <xmqqpomp33km.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kaq85c1Gk1aRSrdQGp1Nm9p6tN0jXbFvTN0v+9ehooxYg@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 7 quoted lines

>> 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.