Re: Subprojects tasks

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 17, 2006, 13:01 UTC
Message-ID: <200612171401.10585.jnareb@gmail.com>
In-Reply-To: <20061217114546.GG12411@admingilde.org>

Martin Waitz wrote:

> On Sun, Dec 17, 2006 at 01:01:09AM +0100, Josef Weidendorfer wrote:

Show 12 quoted lines

>> IMHO it simply is added flexibility to allow a checkout to be separate from
>> the .git/ directory, same as explicitly setting $GIT_DIR would do.
>> So this .gitlink file is on the one hand one kind of convenience for users
>> which want to keep their repository separate, yet do not want to specify
>> $GIT_DIR all the time in front of git commands.
>> The .gitlink file simply makes the linkage to the separate repository
>> persistent.
> 
> I can see the reason for wanting to use another object database,
> but HEAD and index should always be stored together with the
> checked out directory.  So perhaps we just need some smart way to
> search for the object database, but keep the .git directory.

Well, in the .gitlink proposal you could specify GIT_DIR for checkout, or separately: GIT_OBJECT_DIRECTORY, GIT_INDEX_FILE, GIT_REFS_DIRECTORY (does not exist yet), GIT_HEAD_FILE (does not exist yet, and I suppose it wouldn't be easy to implement it). By the way, that's why I'm for .gitlink name for the file, not .git -- this way .gitlink can "shadow" what's in .git, for example specifying in a smart way where to search (where to find) object database, but HEAD and index would be stored together with the checked out directory in .git

By the way, I'm rather partial to supermodule following HEAD in submodule, not specified branch. First, I think it is easier from implementation point of view: you don't have to remember which branch supermodule should take submodule commits from; and this cannot be fixed branch name like 'master'. For example 'maint' branch of supermodule could track 'maint' branch of submodule, 'master' branch of supermodule track 'master' branch of submodule, 'next' branch of supermodule tranck 'master' (!) branch of submodule, 'pu' branch of supermodule track 'next' (!) branch of submodule.

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; the complaint that with tracking HEAD you can check-in wrong version of submodule to supermodule commit doesn't hold, because you still would have problem that _tree_ of supermodule would have wrong version of submodule. And moving to using single defined branch of submodule brings multitude of other problems: for example you might usually track 'master' version of submodule, but for a short time need to track 'next' branch because it has functionality you need; and another time you need to move to 'maint' branch or even your own branch because 'master' version breaks something in supermodule.

Hmmm... I wonder how planned allowing to checking out tags, non-head branches (e.g. tracking/remote branches) and arbitrary commits but forbidding committing when HEAD is not a refs/heads/ branch would affect submodules / subprojects...

-- 
Jakub Narebski