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

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

[Jon Seymour]

Has consideration ever been given to a submodule-like facility where
the configuration information maintained in the supermodule for the
submodule is not a gitlink but is instead the name of a branch (or
generally, a symbolic reference within the nested submodule).

In this case, "git submodule update" would checkout the specified
branch of each submodule rather than the specified commit.

Of course, the intent of such a facility would be to allow git
supermodules to be used to simplify management of a group of related,
yet indOfependent, git projects.

jon.

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

[Junio C Hamano]

Jon Seymour <jon.seymour@gmail.com> writes:

> Has consideration ever been given to a submodule-like facility where
> the configuration information maintained in the supermodule for the
> submodule is not a gitlink but is instead the name of a branch (or
> generally, a symbolic reference within the nested submodule).

I think this comes up from time to time, and there was an even a slightly
more concrete suggestion to us 0{40} in the tree object to denote such an
entry.

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 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.

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

[Dmitrijs Ledkovs]

On 2 May 2010 17:00, Junio C Hamano <gitster@pobox.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> Has consideration ever been given to a submodule-like facility where
>> the configuration information maintained in the supermodule for the
>> submodule is not a gitlink but is instead the name of a branch (or
>> generally, a symbolic reference within the nested submodule).
>
> I think this comes up from time to time, and there was an even a slightly
> more concrete suggestion to us 0{40} in the tree object to denote such an
> entry.
>
> 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 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.
>


Gnome uses jhbuild to build out of git, tarballs and other vcs's. It
has quite a bit of code of recursivly finding & updating all
submodules to the latest tip.

This is want you generally want when you integrate.

When you actually want to lock on a particular revision and not track
upstream branches I believe subtree merge strategy should be used
instead of submodules.

I beleive you should be able to specify symbolic references for the
git submodule to store.

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

[Jon Seymour]

On Mon, May 3, 2010 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> Has consideration ever been given to a submodule-like facility where
>> the configuration information maintained in the supermodule for the
>> submodule is not a gitlink but is instead the name of a branch (or
>> generally, a symbolic reference within the nested submodule).
>
> I think this comes up from time to time, and there was an even a slightly
> more concrete suggestion to us 0{40} in the tree object to denote such an
> entry.
>
> 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.

> 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.

Also needed, I think, would be a way to sync the .gitmodule file with
the current submodule branch assignments.

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.

jon.

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

[Junio C Hamano]

Jon Seymour <jon.seymour@gmail.com> writes:

>> 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.

>> 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 ;-)