Re: Subprojects tasks

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Dec 17, 2006, 23:23 UTC
Message-ID: <200612180023.45815.Josef.Weidendorfer@gmx.de>
In-Reply-To: <20061217134848.GH12411@admingilde.org>

On Sunday 17 December 2006 14:48, Martin Waitz wrote:

Show 5 quoted lines

> The version tracked by the supermodule is completely independent from
> any branches you define in your submodule.
> It is of course possible to use different versions of your submodule in
> different branches of your supermodule.  But the supermodule does not
> know the name of these branches.

I see that you always use "refs/heads/master" in the submodule. What happens if you do development in the submodule, create a new commit there, and want to switch supermodule branch afterwards? Wouldn't you lose your new work, as "refs/heads/master" has to be reset to another commit when you switch the supermodule branch?

IMHO it would be nice to have refs in the submodule matching all the
branches/tags of the supermodule.
Meaning: "this is the commit which is used by branch/tag XYZ in the
supermodule". This can be valuable information, and a "gitk --all" in
the submodule would show you all the uses of your subproject in the
scope of the given superproject.
We could occupy the local refs namespace of the
submodule with the same refs as there are in the supermodule. But that
is no problem as the original branches of the subproject would be
in "refs/remotes/".

When switching branches in the supermodule, it simply would switch to the same name in submodules. The submodule refs would not need to match the submodule object in the tree of the supermodule; instead, it would represent the development done in the submodule while on a given branch in the supermodule. Thus, this would allow to do bug fix commits for a submodule at all places where the supermodule has a branch, without the need to switch supermodule branches. However, "git commit" in branch X in the supermodule should give a warning when submodules are not all at the same branch X, as the commit would use branch X for committing.

Show 11 quoted lines

> > Second, if you want to do some independent work on the module not related
> > to work on submodule you should really clone (clone -l -s) submodule
> > and work in separate checkout;
> 
> Yes.
> But I really like the possibility to switch one module to a branch which
> is not tracked by the parent, because it perhaps contains some debugging
> code which is needed to debug some other submodule.  You can't move it
> out because you need the common build infrastructure but you don't want
> to branch the entire toplevel project because you don't want your
> debugging changes to ever become visible at that level.

In general, I agree with not following submodule's HEAD for supermodule commits. As you cannot store any submodule branch names, this really would be confusing, as after switching to another supermodule branch and back again, the submodule branch name would reset to a given name ("master" in your current implementation).

But why wouldn't you create a temporary branch "debug_submodule1" in the supermodule for your use case? Branches are cheap with git, even in supermodules. Supermodule branches also are pure local, you never have to publish it somewhere, and can delete it afterwards.