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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 25, 2016, 17:15 UTC
Message-ID: <xmqqoa28s63l.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kbtyuSXDiyi2eY6HKCAwEiKgk2KmNakSn=f+RiXCAC1bA@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 13 quoted lines

> 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@mail.gmail.com>

Show 19 quoted lines

> On Sat, Oct 22, 2016 at 10:11 AM, Junio C Hamano <gitster@pobox.com> 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@gitster.mtv.corp.google.com>

Show 19 quoted lines

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