Re: Git 2.7.0 gitignore behaviour regression

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 6 Jan 2016, at 09:42, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> 
> Yeah.. I think it's the only relevant commit in 2.7.0 cycle anyway.
> These patterns "/a" followed by "!/a/*" were wrecking my head. But I
> finally decided 2.7 output makes more sense. You asked to un-ignore
> everything inside 'a' so we can't treat 'a' as (entirely) ignored and
> hide it away.
> 
>> I'm sympathetic that in making that use-case work, we might have
>> regressed another one, but it's hard to tell from the small example. Can
>> you elaborate on your use case? Why are you both ignoring and unignoring
>> everything in the directory?
> 
> Also how bad this affects you (widely-used 'wrong' behavior can become
> 'right', and my change a regression as a result)

This doesn’t affect me badly; I was able to work around the original issue before the bug report in a way that was consistent between Git 2.6 and Git 2.7 but wanted to ensure that I filed something upstream just so it was a known issue as it was relatively easy to reproduce.

I agree that all the pattern handling stuff like in my example is pretty awful; it’s also a big area where libgit2 was inconsistent with Git’s behaviour on either of those versions too. I’ve played around and now got a .gitignore file that behaves consistently across Git 2.6, Git 2.7 and libgit2 0.23.4 (https://github.com/Homebrew/homebrew/blob/master/.gitignore) so there’s no outstanding issue on my side.

Thanks!

Mike McQuaid
http://mikemcquaid.com

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]