Re: What's cooking in git.git (May 2012, #06; Wed, 23)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 24, 2012, 17:01 UTC
- Message-ID
- <7vlikhy0l8.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <4FBDCE26.1080904@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
Show 22 quoted lines
> Am 5/24/2012 7:36, schrieb René Scharfe: >> Am 24.05.2012 00:24, schrieb Junio C Hamano: >>> * rs/maint-grep-F (2012-05-21) 4 commits >>> (merged to 'next' on 2012-05-23 at b24143c) >>> + grep: stop leaking line strings with -f >>> + grep: support newline separated pattern list >>> + grep: factor out do_append_grep_pat() >>> + grep: factor out create_grep_pat() >>> >>> "git grep -F", unlike the case where it reads from a file, did not treat >>> individual lines in the given pattern argument as separate patterns as it >>> should. >> >> This is not specific to -F; grep(1) accepts newline-separated pattern >> lists with -E etc. as well, as does git grep with the patches above. > > Shouldn't we worry that this change breaks existing users? > > Consider a script that generates a pattern that sometimes contains NL. > Yes, it would not match anywhere, but what if that is a deliberate choice > of the script writer? With this change, the script would now observe > spurious matches where earlier there were no matches.
While I prefer to be conservative, and the scenario above may be theoretically possible, I personally find this particular "breakage" of backward compatibility is very well defensible, as the original behaviour is clearly buggy and unintuitive.