Re: Change in .gitignore handling: intended or bug?

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 9, 2016, 00:32 UTC
Message-ID: <xmqq7fhcjxt8.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACsJy8AgPQ__aVgoJc860yapWs_rTbXfBuGSBNRG-FT+v+rK1w@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 15 quoted lines

> On Wed, Mar 9, 2016 at 1:10 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> So what do we want to do for the upcoming release?
>
> I don't know. Befoire 2.8.0, all three matching cases are broken. With
> the current changes on 2.8.0, one case is fixed with the other cases
> broken. I guess it can create even more confusion. Yeah documentation
> helps a bit.
>
>> I am OK to leave
>> the code as-is for now and describe it as a known bug that is still
>> being worked on (as long as it indeed is being worked on, that is),
>
> I do want to fix it. I don't know how much code is impacted yet (and
> how many more bugs I'll be introducing while attempting to fix it). It
> may take a few cycles before the fix can be released.

Sorry, but I should have been more clear. At this point in the release cycle, I do not think it is an option to pile on more "fixes" to risk destabilizing the end-user experience even more before 2.8.0 final happens.

It is between (1) the current code is good enough that with a (temporary) limitation clearly described in the documentation users can work around the implementation deficiency and get a benaviour that is closer than 2.7.2, or (2) the half-way implementation we have does not give enough advancement toward the final goal (i.e. the !dir re-inclusion behaves consistently with the dir that ignores the whole thing underneath, while allowing subpaths ignored with follow-on entries in the same .gitignore file), and we are better off reverting the whole thing to go back to 2.7.2 behaviour, planning to do a better job in the next cycle.

I was hoping that (1) would be the case.