On Sat, May 7, 2016 at 2:18 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Fri, May 6, 2016 at 12:02 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Stefan Beller <sbeller@xxxxxxxxxx> writes: >> >>> On Fri, May 6, 2016 at 3:30 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: >>>> On Fri, May 6, 2016 at 6:27 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>>>> Stefan Beller <sbeller@xxxxxxxxxx> writes: >>>>> >>>>>>> I wonder if the patches mentioned have something to do with the "git >>>>>>> add deep/in/the/tree" that fails to notice deep/in/ is an unrelated >>>>>>> repository in some way? >>>> >>>> The same functionality is added in 8745024 (parse_pathspec: support >>>> stripping/checking submodule paths - 2013-07-14) so if it didn't fail >>>> to notice that before 5a76aff1a6 and did after, it's a bug. >>> >>> The bug seems to have existed before. However in the bug we are talking >>> about the nested repo is not a submodule yet. >> >> That agrees with Duy's recollection below: >> >>>> I vaguely recall this symptom. It has something to do with the index, >>>> the check we do requires a gitlink in the index, I think. So if the >>>> gitlink entry is not in the index, our protection line fails. >> >> So are we all on the same page that this is a bug now? > > It was a bug, but now people in the outside world consider it a feature. > Search for "Git fake submodules" and you'll find a few users who use this > technique successfully. > > I do not think fixing this bug would do good. So maybe we just let it slip? I think it's because people do have some use cases for multiple worktrees (typically from different repos) to share the same filesystem portion. We never actually support that. There are a bunch of questions on how these worktrees/repos should interact. Maybe someone will finally add support for that. But this is still a bug, even though nobody has time to fix it yet. So I agree with Junio calling this "undefined behavior", not "feature". -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html