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
"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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html