Ramkumar Ramachandra <artag...@gmail.com> 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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html