On 13.12.2011 22:44 Jens Lehmann wrote:
Am 13.12.2011 10:45, schrieb Andreas T.Auer:
> On 12.12.2011 23:39 Jens Lehmann wrote:
>> Am 11.12.2011 22:15, schrieb Andreas T.Auer:
>>> 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.
>
> Yes, this has been my first thought also, but there is also a good
> point to keep the .gitmodules stable, or you always have to change
> the file when branches change their names. So when the maint branch
> of version 1.3 become an archive branch and the new maint is on
> 1.4, which was the master before then you have to change the
> .gitmodules on these branches. I.e. .gitmodules of 1.4 have
> "stable" and must have "bugfixes" now and .gitmodules of 1.3 has
> "bugfixes" and must remove the floating completely. I'm not sure
> that this can always be solved with "easy" merging and therefore it
> is probably not really simpler, when you have to do this for every
> new release. Or what do you think?
I never rename branches, so I do not concur ;-)
Well, maybe you don't, but Junio does something like that. There is a
maint-1.7.7 where maint has been before and maint jumped to master.
And I think the .gitmodules file could benefit from a special merge
driver being aware of the format and some subtleties (like not just
adding a "branch" setting but rather creating a merge conflict)
anyways.
If that would work it would be fine, but you would still have to create
a new commit, when maint jumps to master and you need to update the
.gitmodules to be a maint .gitmodules.
So I'd prefer to keep it simple and just use the .gitmodules we
already have which can be different in different branches.
I agree that the .gitmodule format would be simpler, but I'd prefer the
.gitmodule to be a little bit more complex, but more stable.
>>> 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 ...
>
> bisect would leave the branch and therefore uses the recorded SHA1
> for the submodule checkout instead of the tip. "follow-the-tip"
> should only work if the superproject follows the tip.
If you follow a tip there won't be any new SHA-1s recorded during
that following so you could not do a bisect and expect the submodule
to be what the developer had when doing the commits, no?
If you never commit something to the superproject, you wouldn't get
SHA1s recorded, that's right. But when you commit something to the
superproject, why shouldn't the current submodule SHA1 be stored?
Floating is about _ignoring_ the recorded SHA1 in _some_ cases, not
about disabling the recording. So you can bisect to the bad superproject
commit. If you suspect a bad submodule commit causing the problem then
you could still bisect the submodule commits between the recorded SHA1s.
--
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