lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xmqqefymzn6u.fsf@gitster.mtv.corp.google.com>
Date:   Sat, 25 Feb 2017 00:31:21 -0800
From:   Junio C Hamano <gitster@...ox.com>
To:     Willy Tarreau <w@....eu>
Cc:     git@...r.kernel.org, Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [ANNOUNCE] Git v2.12.0

Willy Tarreau <w@....eu> writes:

> Hi Junio,
>
> On Fri, Feb 24, 2017 at 11:28:58AM -0800, Junio C Hamano wrote:
>>  * Use of an empty string that is used for 'everything matches' is
>>    still warned and Git asks users to use a more explicit '.' for that
>>    instead.  The hope is that existing users will not mind this
>>    change, and eventually the warning can be turned into a hard error,
>>    upgrading the deprecation into removal of this (mis)feature.  That
>>    is not scheduled to happen in the upcoming release (yet).
>
> FWIW '.' is not equivalent to '' when it comes to grep or such commands,

I am amused and amazed ;-).  

The above is not about "grep" but was meant to describe "pathspec".
We used to take "" as a pathspec element that means "every path
matches", but recently started deprecating it and ask users to be
more explicit by using "." (as a directory as a pathspec element
matches everything inside the directory).  We are not changing the
pattern matching done by "git grep" or "log --grep".  What is
changing is that between the two that means the same thing:

	cd t/ && git log ""
	cd t/ && git log .

the former is deprecated.

I find it amusing that I have been writing the above in the draft
release notes without realizing that I failed to say that it is
about pathspec for quite some time, and without realizing that the
above can be misinterpreted as if it is talking about grep patterns.

And I find it amazing that it took this long for somebody to spot
that misleading vagueness in this description and point it out.

It should probably be updated to start like so:

	Use of an empty string as a pathspec element that is used
	for 'everything matches' is ...

Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ