Duy Nguyen wrote: > Include me to those everyone. url feels like a local thing that should > not stay in object database (another way of looking at it is like an > email address: the primary one fixed in stone in commits with .mailmap > for future substitution). We've been over this several times in earlier emails. That's like saying that a blob should not be stored in the object database, because it is not "fixed in stone" (my OBJ_LINK is just a special kind of blob, as I've repeated many times already). I don't rely on what I "feel", which is why I started out by posting an implementation: the implementation seems to indicate that getting an OBJ_LINK will simplify a lot of things. And that is my primary criterion for deciding: if the implementation is simple and elegant, it must clearly be doing something right. Again, I'm not saying that my approach is Correct and Final. What I'm saying is: "Here's what I've done. Something interesting is going on. It's probably worth a look?" > Other attributes like .update, > .fetchRecursiveSubmodules... definitely should not be stored in object > database. "Coffee and other beverages definitely should be served cold." All very nice to say, but I don't see any rationale. > I think if they are stored in the submodule's config file, > then the manual move problem above will go away. What? The submodule's .git/config? Why should a submodule repository know that it is being used as a submodule? What inherent properties of a git repository change if it is being used as a submodule? > And if you're dead set on storing some submodule state in object > database, I'm not. I'm just saying that it seems to be an interesting alternative approach. Considering that nobody else brought up a real alternative approach, and chose to just keep defending .gitmodules to the death, it's the only other approach we have. > why not reuse tag object with some nea header lines? Or a unified blob, which is currently what we have. The point is to have structured parseable information that the object-parsing code of git code and easily slurp and give to the rest of git-core. Please clear your reading backlog to avoid bringing up the same points over and over again. -- 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