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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 4, 2013, 18:52 UTC
Message-ID: <CALkWK0nNjvV5VGvT_eaubFoOhMnJ-N8FECAayd5A2K3BzeRh6Q@mail.gmail.com>
In-Reply-To: <CA+55aFz1D_dMtMHHMpiGi3KL=Y-m4DVxHVr=1ZX8zYWQ2TPvwA@mail.gmail.com>

Linus Torvalds wrote:

Show 5 quoted lines

> I don't dispute that a new link object might be a good idea, but
> there's no explanation of the actual format of this thing anywhere,
> and what the real advantages would be. A clearer "this is the design,
> this is the format of the link object, and this is what it buys us"
> would be a good idea.

Yeah, I need help with that. I've just stuffed in whatever fields popped into my mind first. The current ones are:

1. upstream_url: this records the upstream URL.  No need to keep a .gitmodules.

2. checkout_rev: this records the ref to check out the submodule to.
As opposed to a concrete SHA-1, this allows for more flexibility; you
can put refs/heads/master and have truly floating submodules.

3. ref_name: this specifies what name the ref under
refs/modules/<branch>/ should use.

4. floating: this bit specifies whether to record a concrete SHA-1 in
checkout_rev.

5. statthrough: this bit specifies whether git should stat() through
the worktree.  We can turn it off on big repositories for performance
reasons.

Show 6 quoted lines

> Also, one of the arguments against using link
> objects originally was that the format wasn't stable, and in
> particular the address of the actual submodule repository might differ
> for different people. So when adding a new object type, explaining
> *why* the format of such an object is globally stable (since it will
> be part of the SHA1 of the object) is a big deal.

After some discussion, I hope to be able to finalize a list of fields that will suffice for (nearly) everything.