Jens Lehmann wrote: > 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? Yes. > 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 ;-). The only mandatory user-visible behavior change is the absence of .gitmodules. The git submodule subcommand will be have to be present and made to work, whether we like it or not. > (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) Read the configuration from the database? How? Also, I want refs quite badly: I really can't stand repo. > (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) It's very simple to implement: if you turn it into a blob, you can diff and merge as usual. > Disadvantages: > > * Changes in user visible behavior, possible compatibility > problems when Git versions are mixed. Agreed. > * Special tools are needed to edit submodule information where > currently a plain editor is sufficient. Um, I actually really like this. I don't want to cd-to-toplevel, open up my .gitmodules and look for the relevant section. And it's a very simple tool: see the git cat-file that I posted earlier. > * 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. There shouldn't be that many merge conflicts to begin with! It happens because you've stuffed all the information into one gigantic .gitmodules. With links, life is *much* easier: you already have a tight buffer format and a predefined order in which the key/value pairs will appear. But yes, we will require to grow git-core to merge links seamlessly. > * 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)? Adding a submodule untracked (not unstaged) is possible, and is default: git clone gets the submodules, and you have to use git add to stage it. I agree that you can't edit-link and have an unstaged change, but I really don't care about that. > (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) Hm, considering that the information is not present anywhere (certainly not in the tree), this is probably a good idea. We'd have the history of the submodule's name too. > 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? Yes, good 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