Am 07.04.2013 20:44, schrieb Ramkumar Ramachandra: > Jens Lehmann wrote: >> The whole feature list is full of red herrings like this which >> have nothing to do with the advantages of a new object, but talk >> about UI issues which are easy to solve in both worlds. > > Really? git-submodule.sh was written in 2007, and does not have git > mv or cd-to-toplevel restriction removed to date. What does that say > about git-submodule? That there is still some work to do, which I never denied and am actively working on (see "git mv" support in pu, which tackles one of the UI issues you mentioned). > I specifically said end-user's perspective. Why exactly would I be > talking about the advantages of the link object? Because they are all that matters when it comes to decide if a link object should be introduced to replace the current model. We should discuss the differences in the UI that result from introducing such an object, not the stuff that is still missing from our current implementation (as that has to be coded either way and can not be taken in favor of either solution). And we can additionally also talk about the differences in hacking on git, where I concede that putting everything into a single object could lead to shorter code than having to consult a .gitmodules file for that (even though I believe these arguments are much less important than UI changes). Just to be sure: I think we agree that both approaches are capable of allowing all relevant use cases, because they store the same information? Disclaimer: I am not opposed to the link object per se, but after all we are talking about severely changing user visible behavior. So I want to see striking evidence that we gain something from it, discussed separately from UI deficiencies of the current code (no cd-to-toplevel please ;-). So I started putting together a list of advantages and one of disadvantages of the new link object compared to the current model. We can extend and refine that to see what your proposal would mean for us. After all we are talking about severely changing user visible behavior, so we need convincing reasons to do that. 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. (I did not forget to add the point that you currently need a checked out work tree to access the .gitmodules file, as there is ongoing work to read the configuration directly from the database) (Another advantage would be that it is easier to merge the link object, but a - still to be coded - .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. * 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. * A link object has no unstaged counterpart that a file easily has. What would that mean for adding a submodule and then unstaging it (or how could we add a submodule unstaged, like you proposed in another email)? (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) I'm not saying that this list is complete, I just wrote down what came to mind. When we e.g. find workable solutions to the Disadvantages we can remove them from the list and append them in parentheses for later reference like I did here. Does that sound like a plan? -- 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