Thread (1 message) 1 message, 1 author, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:08:40

Duy Nguyen [off-list ref] writes:
On Wed, Mar 9, 2016 at 1:10 AM, Junio C Hamano [off-list ref] wrote:
quoted
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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help