Re: git-submodule getting submodules from the parent repository

["Avery Pennarun" <apenwarr@gmail.com>]

On 4/1/08, Sam Vilain <sam@vilain.net> wrote:
>  > The ideal situation would be to have
>  > git just manage the version control without having to babysit it, of
>  > course.
>
> I can understand the motivation to write such disparaging remarks;
>  however it may be more productive to come up with good ideas about how
>  it can be made to work better for you, without getting in the way of
>  other users.  patches are even better!

I didn't mean anything disparaging.  I have nothing against babysitters :)

I'll be happy to work on patches once we have some sort of consensus
on what would be desirable.  I think we're slowly getting there.

>  >>  If I understand you correctly, you want to be forced to create a
>  >>  branch and push to that?  I don't think that works well with many
>  >>  developers pushing to a shared repository (my situation),
>  >
>  > Hmm, this is curious.  If you're *not* using submodules, then I don't
>  > think you can push successfully without being on a branch, can you?
>
> Sure, you could;
>
>   git push origin HEAD:branchname

Okay, yes.  But that's just arbitrarily avoiding a local branch and
creating a remote one instead.  I can't imagine a situation where
you'd really want the local branch to be anonymous while the remote
one is not.

When doing a normal "git clone" without submodules, git automatically
creates you a local branch with the same name as the remote's
.git/HEAD - which is rather arbitrary, but even an arbitrary local
name is better than no name, and when checking out a brand new
submodule, there are *no* local branches, so a name conflict is
impossible.

>  > If you 'git checkout -b branchname' inside a submodule, then 'git
>  > push' will do the right thing, so I'm not sure what you'd want to be
>  > more automagical than that.
>
> Well, where did you get the branch name from?  That's the part that
>  requires user intervention.  You could make an educated guess, such as
>  with git name-rev, but it would not necessarily be the right guess - so
>  user confirmation of the choice would be desirable.

Here's a paraphrase of what I suggested earlier.  I don't think it got
a response:

Instead of storing only the commitid of each submodule in the parent
tree, store the current branch name as well.  Use this as a hint to
'submodule update' so that when it checks out commitid, it names the
local branch with the same name as it used to have.  (This is rather
user-friendly since if I check in, push, and clone, my new submodule
checkout will have the same branchname as it used to have.)

Note that the newly checked-out submodule branch will probably have
the same name as as remote branch.  However, the remote branch may
refer to a different commitid (for example, if someone has pushed to
that branch after the parent repo was last updated).  This is exactly
right; it means that if I cd into the submodule and "git push", it'll
fail because I'm not up to date (I can always switch to a new branch
if I want), and if I "git pull", it'll pull from the place where it
should.

This way, cloning a project with submodules will work much like
cloning the parent project; pushing and pulling the parent and the
submodules will do as you expect.

The bad news is that this would require a change to the tree format
for submodules (to contain the branch name).  Is that a problem?  Can
it be done in a backwards-compatible way?

Also, I think this is the only time I've seen a branch name in the
commit/tree structure, which normally refers only to sha-1 hashes.  Is
that a problem?  Is there a better way?

Thanks,

Avery