Stefan Beller <sbeller@xxxxxxxxxx> writes:
> 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 am OK with leaving it unfixed, iow, we just say this:
If deep/in is a different repository, whether it is a submodule,
"git add deep/in/the/tree/is-a-leaf.txt" will give an undefined
result.
But that is totally different from accepting it as a feature. If we
were to accept it as a feature (and we will not), then
I did "git add deep/in/the/tree/is-a-leaf.txt" and have kept the
path tracked. Today I did "git add deep/*" and then the path
disappeared from my project--I now only have deep/in as a
submodule, which is not what I want.
would become a valid bug report. I do not want to see that happen.
I.e. I am *NOT* OK with polluting the codebase with a hack to
respond to such a bug report, e.g. by adding a rule that says "if a
file deep/in/the/tree/is-a-leaf.txt is tracked and deep/in is a
repository, 'git add deep/in' must fail".
The stance "It is a bug, but we do not fix it right now. The
behaviour is undefined" also leaves the door open for a future
enhancement that allows 'git add deep/in/the/tree/is-a-leaf.txt' to
be an equivalent to 'git -C deep/in/the/tree add is-a-leaf.txt'.
--
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