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

Reply via email to