Am 28.03.23 um 15:47 schrieb Junio C Hamano: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> I suspect that 54463d32ef was done in a conservative way to avoid >> unintended side effects to make ERE "enhanced". I am not 100% >> certain, but after reading the documentation you pointed at, I do >> not see a valid expression without ENHANCED flag starting to mean >> totally different thing with it (well, an extra '?' turning a >> pattern from greedy to minimal may count as such a change in >> semantics, but I do not see anybody sensible adding an extra '?' >> in a pattern in the first place). > > Sorry, but that is nonsense. We cannot avoid being backward > incompatible if we suddenly flip the "enhanced" bit for BRE. A > sane pattern written expecting non-enhanced BRE can change its > meaning when the "enhanced" mode is enabled. Right, and there are even more enhancements for ERE, i.e. more incompatibilities. Not sure how big of a problem that actually would be, though. > But if "enhanced" is what users want, and if that is what the other > tools on the platform use, then perhaps flipping the "enhanced" bit > may not be a bad idea. Apple's grep(1) uses it, with and without -E: https://github.com/apple-oss-distributions/text_cmds/search?q=REG_ENHANCED E.g. awk(1) and sed(1) don't, AFAICS. René
