On 12.12.2011 19:04 Leif Gruenwoldt wrote:
On Mon, Dec 12, 2011 at 10:34 AM, Andreas T.Auer <andreas.t.auer_gtml_37453@xxxxxxxxxxxx> wrote: > So you don't want to add a new commit to the products A, B and C > repos whenever the stable branch of the submodule changes, but on > the other hand when you commit changes to the products it would > still make sense to update the gitlink to the current commonlib > version together with your changes, too, right? Hmm I supose that does make sense. If the commonlib version was auto recorded during a commit of the product it would be nice. Then if/when the user reconfigured the submodule from "floating" to "strict" mode it would then have a submodule sha1 reference. I like how this sounds.
The next question is: Wouldn't you like to have the new stable branch only pulled in, when the projectX (as the superproject) is currently on that new development branch (maybe master)?
But if you checkout that fixed released version 1.2.9.8, wouldn't it be better that in that case the gitlinked version of the submodule is checked out instead of some unrelated new version? I mean, when the gitlinks are tracked with the projectX commits, this should work well.
And what about a maintenance branch, which is not a fixed version but a quite stable branch which should only have bugfixes. Shouldn't the auto-pull be disabled in that case, too?
I think the "auto-pull" behavior should depend on the currently checked out branch. So the configuration options should allow the definition of one or more mappings.
-- 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