Stefan Beller <sbeller@xxxxxxxxxx> writes:
> One of the initial ways to work around the bugfix was to
>
> git clone . root # <- add in this step and it works again.
> git clone root super
>
> but instead I will do the preparation for the 'super' project not
> in '.' but in 'root', just called differently ("super_remote" ?)
>
> An additional new test for cloning from '.' will be introduced, too.
>
> I plan on working on that with highest priority for git after finishing
> some attr stuff that I currently have open. So expect a patch (or two)
> this week.
Hmph, I personally would prefer to defer the "correct behaviour for
/." part for the next cycle, which is why I wrote:
- the "off-by-one fix" part of sb/submodule-ignore-trailing-slash
needs to be in the upcoming release but the "trailing /. in base
should not affect the resolution of ../relative/path" part that
is still under discussion can wait. Which means we'd need a few
more !MINGW prerequisites in the tests by -rc0.
at the beginning of the message you are responding to, and I also
thought that was consistent and in agreement with what you said
earlier in <CAGZ79kaq85c1Gk1aRSrdQGp1Nm9p6tN0jXbFvTN0v+9ehooxYg@xxxxxxxxxxxxxx>
> On Sat, Oct 22, 2016 at 10:11 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> >
> > There isn't enough time to include this topic in the upcoming
> > release within the current https://tinyurl.com/gitCal calendar,
> > however, which places the final on Nov 11th.
> >
> > I am wondering if it makes sense to delay 2.11 by moving the final
> > by 4 weeks to Dec 9th.
> >
> > Thoughts?
> >
> > 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.
to which I responded in <xmqqpomp33km.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> 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.
So...