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

Reply via email to