On Tue, Jul 18, 2017 at 11:00 AM, Brandon Williams <bmwill@xxxxxxxxxx> wrote: > On 07/18, Junio C Hamano wrote: >> Stefan Beller <sbeller@xxxxxxxxxx> writes: >> >> >> I'd be more worried about segfault we seem to be getting only on >> >> Windows from this: >> >> >> >> git -C parent grep -e "(1|2)d(3|4)" --recurse-submodules HEAD^ > actual >> >> >> >> in https://travis-ci.org/git/git/jobs/254654195 by the way. >> > >> > Thanks for bringing that to my attention, (I do not follow the travis builds >> > as closely, as there is no yelling email in my inbox). >> > >> > Windows builds on travis seem to be flaky. >> > (sometimes they do not start), but there are also >> > successful builds, including the -rc0, which may indicate >> > bw/grep-recurse-submodules may be faulty on Windows. >> >> I can get valgrind complaints locally from >> >> $ cd t && sh t7814-grep*.sh --valgrind -i -v >> >> so this may not be Windows only. Can repo_worktree_path() return a NULL >> in repo_read_gitmodules() to cause git_config_from_file() barf on a NULL >> gitmodule_path? > > Yep that's most likely the cause. The issue is if a repository doesn't > have a worktree then what should a worktree path look like? > repo_read_gitmodules() should check if there is a worktree before trying > to load the gitmodules file. I actually noticed this and have it fixed locally in > another series I'm working on right now. Looks like I may have to get > that change in first though. Thanks for finding this. If there is no worktree, we could fallback to read it from the tree HEAD:.gitmodules, if that doesn't exist, then there are no submodules. Thanks, Stefan
