On Tue, Jun 19, 2018 at 6:09 PM Duy Nguyen <pclo...@gmail.com> wrote: > On Tue, Jun 19, 2018 at 05:16:17PM +0200, Duy Nguyen wrote: > > No actually, we could do better. Let me see if I can come up with a > > patch or something... > > OK. What we currently do is, when we search for potential untracked > paths for adding to the index, we unconditionally ignore anything > inside ".git". For example, if "foo" is a submodule, "git add ." will > visit "foo/.git" then ignore its content completely. > > We could do something very similar: when we visit "foo", if "foo/.git" > exists, we ignore it as well. In other words, we extend from "ignore > anything inside a git repository" to "ignore anything inside any other > git worktree". > > The following patch basically does that. If you specify "git add > foo/bar". It will still visit "foo" first, realize that it's a > submodule and drop it. At the end, it will not report foo/bar as an > untracked (i.e. add-able) entry, so you can't add it.
Another note (which I added, then thought otherwise and dropped). I believe this approach also solves the problem that die_path_inside_submodule() tries to work around. When you feed a path inside a submodule, read_directory() code does not realize it and walk through like it's part of the current worktree (wrong!). But if read_directory() does the right thing from the beginning, you don't need this trick. We don't even need this trick if a submodule is not real on worktree (no ".git" directory there) but registered in the index as a git link because the d/f check should catch that and complain loudly anyway when you add a new entry. -- Duy
