Ok, here comes an updated version of our comparison list which
I updated with what I read in recent discussions. As I said
earlier, please speak up if I missed anything (or forgot to add
anyone to the CC).
I picked up one advantage ("no need to cd-to-toplevel to edit
.gitmodules) two new disadvantages ("foreach" and "default
submodule config") and retired one Ram showed a solution for
(the "unstaged gitlink").
Advantages:
* Information is stored in one place, no need to lookup stuff in
another file/blob.
* Easier coding, as we find all information in a single object.
* No need to cd-to-toplevel to change configuration in the
.gitmodules file, the special tools to edit link information
will work in any subdirectory.
(We currently need a checked out work tree to access the
.gitmodules file, but there is ongoing work to read the
configuration directly from the database)
(While it is easier to merge the link object, a .gitmodules
aware merge driver would work just as well)
Disadvantages:
* Changes in user visible behavior, possible compatibility
problems when Git versions are mixed.
* Special tools are needed to edit submodule information where
currently a plain editor is sufficient and a standard format
is used.
* merge conflicts are harder to resolve and require special git
commands, solving them in .gitmodules is way more intuitive
as users are already used to conflict markers.
* "git submodule foreach" becomes harder to implement
* With .gitmodules we lose a central spot where configuration
concerning many submodules can be stored
(I think when we also put the submodule name in the object we
could also retain the ability to repopulated moved submodules
from their old repo, which is found by that name)
(That a link object can have no unstaged counterpart that a file
easily has can be fixed by special casing this, e.g. in using a
file in .git/link-specs/)
Hmm, while it is still too early to close the polls, it looks
to me as most advantages are about easier coding while most
disadvantages hit the user. That makes it more understandable
for me why Ram is so convinced of his approach and why on the
other hand submodule users like myself are rather sceptical. I
think we need some more advantages that users will directly
profit from, the cd-to-toplevel for .gitmodules is definitely
not enough to support the change Ram is proposing. What other
advantages are missing here?
--
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