Hi Alexander, On Tue, Nov 13, 2018 at 12:36 AM Alexander Kapshuk <alexander.kaps...@gmail.com> wrote: > > On Tue, Nov 13, 2018 at 2:09 AM Brian Norris <briannor...@chromium.org> wrote: > > > > On Mon, Nov 12, 2018 at 10:42:26AM +0200, Alexander Kapshuk wrote: > > > An even simpler approach would be: > > > > > > { > > > git --no-optional-locks status -uno --porcelain 2>/dev/null || > > > git diff-index --name-only HEAD > > > } | grep -qv scripts/package && > > > printf '%s' -dirty > > > > > > Sample run: > > > cmd > > > sh: cmd: command not found > > > > > > { > > > cmd 2>/dev/null || > > > date > > > } | grep -q 2018 && > > > printf '%s' ok > > > ok > > > > You lose accuracy here, because now you're skipping any line that > > contains 'scripts/package', which would include, e.g., paths like > > > > tools/some/other-scripts/package > > > > Maybe if the grep expression were more like this? > > > > grep -qv '^\(.. \)\?scripts/package' > > > > I think it'd be safe enough to ignore paths that start with two > > characters and a space, like: > > > > xy scripts/package > > x/ scripts/package > > > > Brian > > Thanks for your input. > I've found the following grep command, that uses extended regular > expressions, to work as required:
Is there any good reason you switched to extended? It looks like my (basic regex) grep was equivalent. > { > echo hello > echo scripts/package > echo '.. scripts/package' > echo tools/some/other-scripts/package > } | grep -Ev '^(.. )?scripts/package' > > [Output] > hello > tools/some/other-scripts/package > > If the participants of this email exchange consider the proposed > implementation as fitting the bill, > > { > git --no-optional-locks status -uno --porcelain 2>/dev/null || > git diff-index --name-only HEAD > } | grep -Eqv '^(.. )?scripts/package' && > printf '%s' -dirty > > Was the original committer of the patch proposed here, > https://lkml.org/lkml/2018/11/10/55, going to take it in, and resend it > as v2 of the patch, or did you want me to submit the patch instead? > I would be happy with either way. I can submit it. I expect Masahiro-san would prefer a proper v2 patch for review, given how much would change from my v1. And this time, I'll actually test it with a non-dirty tree! (Of course, my tree is naturally dirty when developing the patch, but I missed testing post-commit...) Brian