Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)

Stefan Beller [off-list ref] 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 [ref]

On Sat, Oct 22, 2016 at 10:11 AM, Junio C Hamano [off-list ref] wrote:

quoted

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 [ref]

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 ;-)

quoted

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