Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > 1. Having a toplevel .gitmodules means that any git-core command like > add/ rm/ mv will be burdened with looking for the .gitmodules at the > toplevel of the worktree and editing it appropriately along with > whatever it was built to do (ie. writing to the index and committing > it). Burdened is a subjective word. What's bad about having a single place you know you can read and find out information about things? You have to learn about them to do anything specific to them anyway. > This is highly unnatural. Unnatural is a subjective word, and there is no justification I see here in your message. > Putting the information in link > objects means that we get a more natural UI + warts like > cd-to-toplevel disappear with no extra code. I do not see how "link objects" _means_ "natural UI", yet, without an explanation how one leads to the other. What does cd-to-toplevel have anything to do with it? In case you did not notice, all the core commands internally cd-to-toplevel and carry the "prefix" information while doing so, and prepend the prefix to user-supplied paths to find which path the user is talking about. So "cd to toplevel before starting to carry the operation out" is a natural pattern inside Git. As many people already told you, "the user has to run 'git submodule' from the top-level of the submodule working tree" is a simple oversight of the implementation. > 2. If we want to make git-submodule a part of git-core (which I think > everyone agrees with), we will need to make the information in > .gitmodules available more easily to the rest of git-core. Care to define "more easily" which is another subjective word? The .gitmodules file uses the bog-standard configuration format that can be easily read with the config.c infrastructure. It is a separate matter that git_config() API is cumbersome to use, but improving it would help not just .gitmodules but also the regular non-submodule users of Git. There is a topic in the works to read data in that format from core Heiko is working on. -- 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