Re: RFD: a submodule-like facility that tracks branches rather than commits

Jon Seymour [off-list ref] writes:

quoted

But once people realize that there is no single canonical authoritative
repository whose branch heads point at the same commits for everybody in a
distributed environment, the line of thought to touch gitlink entries gets
retracted or discarded as a misguided idea.

I understand the point about there being no canonical authority,
particularly in a truly distributed environment - any use of branches
would have to imply that users followed some convention when
publishing the entire set.

On the other hand, there is actually precedent for use of convention
like that in the submodule facility - the use of relative paths to
describe the relative locations of submodule repos only really works
if everyone who publishes the supermodule uses the filesystem
structure for the directories containing the super- and sub-module
repos.

That's not exactly what I meant.

If the superproject commit didn't record the exact commit for each
submodule, and only said "the tip of branch X" (presumably "as of this
writing"), then there is no way to reliably reproduce the build product
given the superproject commit alone.

quoted

I however don't think it would hurt to enrich .gitmodules with not just
the repository information but with branch information to help clones
decide which commit (other than what is recorded in the tree of the
superproject's commit) on the named remote tracking branch to try out with
the superproject's commit.

I can see that this could work. Presumably git submodule sync would be
modified in this case to help switch branches.

There are two ways to use submodules.  As I said already, the superproject
commit records exact commit for each submodule by design, to ensure that
the exact state including submodules can be reproduced.  You manage
submodules as separate projects, and the top level superproject commit
picks a _good_ commit suitable for the purpose of the superproject, not
just a random one that happens to be at the tip for a given day, to use
from the submodule.

But it is not implausible for the top level maintainer of thesuperproject
of a project not to even care about what s/he is shipping exactly, and
instead wish to describe "under this top level directory, check out these
projects my colleagues have as subdirectories" and nothing else.  In such
a case, the exact commit for each submodule recorded in the superproject
still can be used to reproduce the exact state if the top level maintainer
cared, but you can instead _choose to ignore_ that information and check
out the random commit that happen to be at the tip of the named branch.
It could appear that such a use pattern is abusing the submodule support
merely to implement a glorified ftp, but in a project that is run that
way, everybody understands and agrees that the commit object recorded in
the superproject is meaningless, so there is no harm done.

I guess there is no reason why I cannot prototype a facility of this
kind with a local helper script. If I it ends up being useful, I'll
consider posting a patch.

Yes, that's the spirit ;-)