Thanks for looking into this. I was able to reproduce it from scratch, but I followed my earlier workflow where I first created the subrepos, and then later renamed it. At the time I was not able to find any command to rename without changing the path (and I was not able find one now either, is there any?), so I edited name and path in .gitmodules and ran git submodule sync. Am I asking for trouble doing it that way? Let me know if you need the exact steps I followed. Andreas On 19 December 2017 at 23:33, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Tue, Dec 19, 2017 at 2:19 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Stefan Beller <sbeller@xxxxxxxxxx> writes: >> >>> I tried reproducing the issue (based on the `next` branch, not 2.15, >>> but I do not recall any changes in the submodule area lately), and >>> could not come up with a reproduction recipe,... >> >> I do not offhand recall anything; the closest I can think of is the >> three-patch series <20171016135623.GA12756@xxxxxxxxxxxxxxx> that >> taught the on-demand recursive fetch to pay attention to the location >> in the superproject tree a submodule is bound to. > > I tried the same test on 2.15 and cannot reproduce there either. > >> >> 4b4acedd61 submodule: simplify decision tree whether to or not to fetch >> c68f837576 implement fetching of moved submodules >> 01ce12252c fetch: add test to make sure we stay backwards compatible >> >> But IIRC, "submodule update" uses a separate codepath? > > Yes, any portion of git-submodule.sh that calls out to C is going > through the submodule--helper. I want to revive the port of that > shell script to C again. > > The "submodule update" uses the submodule helper to obtain > the list of submodules and then does a "git -C $sub fetch" in there. > > Stefan
