Re: git-submodule getting submodules from the parent repository

From: Avery Pennarun <apenwarr@gmail.com>
Date: Apr 1, 2008, 23:56 UTC
Message-ID: <32541b130804011656l2e907895i98e5260b49743bbe@mail.gmail.com>
In-Reply-To: <47F2BFCD.5070202@vilain.net>

On 4/1/08, Sam Vilain <sam@vilain.net> wrote:

Show 8 quoted lines

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

Show 10 quoted lines

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

Show 8 quoted lines

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