Re: Subprojects tasks

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Dec 18, 2006, 10:30 UTC
Message-ID: <200612181130.18652.Josef.Weidendorfer@gmx.de>
In-Reply-To: <20061218074441.GJ12411@admingilde.org>

On Monday 18 December 2006 08:44, Martin Waitz wrote:

Show 11 quoted lines

> On Mon, Dec 18, 2006 at 12:23:45AM +0100, Josef Weidendorfer wrote:
> > 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?
> 
> It should behave the same as for files:
> Refuse to update the working directory if files (or the submodule here)
> are dirty.  I guess this is not yet handled correctly by my prototype,
> but it should not be hard to do.

Ah, I see. Yes, this is consistent with other dirty files.

Show 9 quoted lines

> > 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.
> 
> I like the idea.  Perhaps make them available similiar to the remotes
> information in refs/tracked/{heads,tags} or something.

Yes. However, you want to do development on these branches. And "refs/tracked/..." is read-only. However, taking the whole local refs namespace is not good, as you perhaps want branches independent of the supermodule, which could give name conflicts. What about using "refs/{heads,tags}/supermodule/..."? This could be a compromise.

Show 7 quoted lines

> > When switching branches in the supermodule, it simply would switch
> > to the same name in submodules.
> 
> Nice idea, but I don't yet know how it really works out.
> It may be confusing to the user if he manually switches the branch in
> the submodule to another branch of the supermodule.  Then he really is
> using one tracked branch, but not the currently tracked branch.

But you already have the same problem with your current approach, don't you?

Actually, the most expected thing for the user really would be to use HEAD in supermodule commits. Every other behavior can get confusing for the user: (S)He simply expects the state of the checkout to be committed. Any branch switching in submodules should be temporary.

Actually, you can be on a temporary branch in a submodule and still switch branches in the supermodule. It is the same as with dirty files: The modifications can be carried over to other branches and back, as long as there are no conflicts.

However, I think it is important to check that you are back on the right branch when committing. With warning or even error.