Re: [RFC/PATCH 0/7] Rework git core for native submodules

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 17, 2013, 11:56 UTC
Message-ID: <CALkWK0m9QmZaSDruY=+2F-Kkw+fd6E1TYCTBpVQHRJrzq2VjCQ@mail.gmail.com>
In-Reply-To: <CACsJy8Bz+yNefiiwEivaaUgRymHTmUUKEFs8_uuonhmRfT3UGg@mail.gmail.com>

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.