Re: git-submodule getting submodules from the parent repository

[Sam Vilain <sam@vilain.net>]

Avery Pennarun wrote:
>>  > 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.

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

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

> 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