Am 18.04.2013 01:17, schrieb Philip Oakley:
> Would it be possible to summarise the key points and proposals of where the subject is now?
Here you go, time to post our third iteration of the comparison
list, containing two updates:
- "easier coding" was removed from the advantages
- "git submodule foreach" was retired from the disadvantages
As in the two first versions, the issues in parentheses had been
brought up but were dismissed and are only kept for reference
together with the reason why they aren't relevant anymore. Only
those preceded by a '*' are still considered valid.
Advantages:
* Information is stored in one place, no need to lookup stuff in
another file/blob.
* 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.
(It is all but clear that this approach will lead to "easier
coding", some parts of the code - like rm and mv - will profit
from that while others won't, e.g. we have to implement the link
object manipulation tools that are not needed for .gitmodules
and we get another indirection retrieving the submodule commit
from the link object. And then there is the fact that the new
code would have to catch up with functionality already coded
using .gitmodules, like the status/diff ignore and the fetch
flags).
(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, 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.
* With .gitmodules we lose a central spot where configuration
concerning many submodules can be stored
("git submodule foreach" becomes harder to implement" is not the
case, as that command currently also walks all tree objects and
does not read the list of submodules from the .gitmodules file)
(When we also put the submodule name in the link 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/)
As no new arguments have been brought up, it all boils down to a
change that'll hurt users badly and won't fix any issue relevant
to them. It'll bring them a flag day after which the .gitmodules
is gone and they'll have to learn new tools to update and merge
the submodule metadata (and not only the users, GUIs have to
follow and implement support for something which currently is a
perfectly normal merge conflict in a file). You'd have to smoke
really weird stuff to even consider such a change under these
circumstances (or you don't care one bit about your users).
> The submodules does need 'fixing', as does agreeing the problem and abuse cases.
Sure, but almost all problems I know about are work tree related,
so changing the internal representation buys us nothing here. It
will not magically do a bisect over submodules or will recursively
update submodule work trees, and all that stuff won't be easier to
code either just because we have to get the information from a new
object instead of a gitlink/.gitmodules combo.
Let's just close this case and get back to working on things that
users will actually profit from.
--
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