Re: [RFC/PATCH 0/7] Rework git core for native submodules

Am 18.04.2013 01:17, schrieb Philip Oakley:

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).

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.