Re: git-submodule getting submodules from the parent repository

From: Sam Vilain <sam@vilain.net>
Date: Apr 2, 2008, 20:06 UTC
Message-ID: <47F3E74C.5010804@vilain.net>
In-Reply-To: <32541b130804011903u3b5d0794w984e26c4570c4688@mail.gmail.com>

Avery Pennarun wrote:

Show 12 quoted lines

>>  > Instead of storing only the commitid of each submodule in the parent
>>  > tree, store the current branch name as well.
>> That goes quite against the fundamental design of git submodules in that
>>  the submodules are by themselves independent entities.
>>     
> Not sure what you mean here; the supermodule already stores the
> commitid of the submodule.  All I'm proposing is that it also store
> the default branchname (ie. the branchname that the submodule was
> using when its gitlink was checked into the supermodule) along with
> that commitid.  The submodule never knows anything about the
> supermodule.
>

How about this.

This could be an optional disambiguator in .gitmodules in the superproject, to allow you to "store the branch it was made from". Glue to make this automatic/easy optional.

When updating a submodule, with an option set (or configured; which might even later become a default if people like it enough), it will try to figure out a reasonable branch for that commit, using git-name-rev, and check out the branch with that name. It first uses the hint above as an argument to git-name-rev --refs=XX, and if that doesn't provide a reasonable answer then look for any branch.

I think this approach would not get in the way of people who don't want to use it, and provide for making things automatic for those who want that.

Show 8 quoted lines

> I agree that the submodule should have its HEAD pointing at exactly
> the superproject-specified commit.  However, I believe this commit
> should have a local branch name (in the subproject) attached to it, or
> else (as I and my co-workers have frequently experienced) people will
> accidentally check in to a nameless branch, causing 'git push' to
> silently not upload anything, and thus lose track of their commits.  I
> have lost work this way.
>

I think this is a separate argument against git-push, the default behaviour of which also causes me to tell people not to use the argument-less form of git-push until they understand how to use the two-argument form.

In the context of git-submodule, adding features to it to avoid this if that is the way that the user wants to work would be good IMHO.

> The idea of naming the local-subproject-branch with the same name as
> it had on checking is that then "git pull" in the subproject will work
> exactly as expected:

It's not really the local branch name anyway, it's how the default push gets configured; perhaps it's worth distinguishing which part you are interested in.

Show 9 quoted lines

> The super-summary of all that is I think I'd like to make three git
> changes here:
>
> 1) When checking out a submodule from scratch, use the local
> supermodule as a --alternate.  That way if both super and submodule
> are hosted in the same remote repo, I don't have to clone them twice.
> (And cloning my local repo to another copy doesn't stop git-submodule
> from working.)
>

Yes - you've already seen the SoC plan for that, although I believe no students applied for that one, and if you think it's minor enough to do, great.

Show 6 quoted lines

> 2) When checking out a submodule, give the submodule's current commit
> a useful branch name (ideally, the name it had when the gitlink was
> checked into the supermodule).  When updating a submodule with
> git-submodule-update, quietly fixup the submodule's local branch ref
> if it hasn't been changed; else produce a conflict of some sort.
>

See above for how I think that should work.

> 3) Bonus: make "git push" operate recursively on submodules, and "git
> pull" automatically run git-submodule-update.
>

I'd appreciate that feature - though I'm more interested in making sure that I don't push anything where the submodule commit is not available via the URL listed in .gitmodules.

Presuming such a check, would that check happen at push time, or do you check at a different time, such as when committing, or when adding the submodule to the index?

I think checking that referential integrity is something perhaps easier to bite off and get people to agree on. I think it would solve the overall process problem, by forcing people to push the submodule before the commit of the superproject can succeed without forcing.

Thoughts/comments? Sam