Am 11.12.2011 22:15, schrieb Andreas T.Auer:
>
>
> On 10.12.2011 00:57 Phil Hord wrote:
>> On Thu, Dec 8, 2011 at 4:13 AM,
>> <andreas.t.auer_gtml_37453@xxxxxxxxxxxx> wrote:
>>
>> Yes, but maybe you can update this information in the .gitmodules
>> file easily with a command. Maybe it could be something simpler
>> than "git sync-gitmodules-branches", but that is essentially what it
>> would do: it would save the current branch in each submodule as the
>> "tracked" branch in the .gitmodules file.
>
> Ok, I have read a better description of the "floating submodule" model now, so it is a different use case and somehow it makes sense. In that case there are probably just a few branches that you would like to follow, maybe an "unstable" for the newest development or "stable" for the current release or some maintenance branches.
>
>> Now this makes sense. I want the same thing. I want to preserve
>> history on "old" commits, but I want to "advance to tip" on "new"
>> commits.
>>
>> The trouble, I think, is in telling the difference between "old" and
>> "new". I think it means there is a switch, like --auto-follow (or
>> --no-auto-follow for the alternate if core.auto_follow is set). But
>> having a config option as the default is likely to break lots of
>> scripts.
>
> In my use case the branches on the submodules follow the superproject and (mostly) versions that are committed there, it just adds the possibility to keep on working without checking out a branch after an update and without colliding with existing branchnames in the submodule.
Using superproject branch names in the submodules make no sense for a
lot of use cases.
> The other use case wants to follow the commits of that other submodule without checking the corresponding gitlinks into the superproject. But wouldn't it also make sense here to define actually a mapping in the .gitmodule that says "if the branch 'develop' is checkedout in the supermodule then with every submodule update automatically pull the newest 'unstable' commit from the submodule"? Or for "master" follow "stable" or for the "maint" branch follow updates in the "bugfixes" branch.
>
> For example
>
> [submodule "commonlib"]
> update = heads develop:unstable master:stable maint:bugfixes
Having that configured with "branch=unstable", "branch=stable" etc. in
.gitmodules on the superprojects branches would be simpler and achieve
the same functionality.
> So whenever a defined branch is checked out in the superproject the mapped branch will be checked out in the submodule ("new" commit), but if a (e.g. tagged) commit is checked out ("old" commit) then the gitlink in the superproject is used to check out the referenced commit in the submodule.
I think checkout should only use the submodule commit recorded in the
superproject and a subsequent "git submodule update" should be needed
to update the submodule to tip. Otherwise you record SHA-1 but still
won't be able to bisect ...
> In http://thread.gmane.org/gmane.comp.version-control.git/183837 was discussed whether the gitlink in the superproject should be set to all-zero if updates follow the tip or maybe use the SHA1 of the commit when the submodule was added. I think the gitlink should be updated everytime when a new commit in the superproject is created.
Nope, only when "git submodule update" is run. Otherwise you'll spray the
history with submodule updates totally unrelated to the commits in the
superproject, which is rather confusing.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html