Am 13.12.2011 00:43, schrieb Phil Hord: > On Mon, Dec 12, 2011 at 5:39 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: >> Am 11.12.2011 22:15, schrieb Andreas T.Auer: >>> 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. > > And this is why my superproject is a makefile, a .gitmodules file and > a bunch of gitlinks. We only use it to track the advancement of > submodule activity. Which is fine. Did you think about having a branch where only the submodules are updated (and built and tested) and committed to by a buildbot when everything is fine? You could then merge that branch whenever you want up-to-date submodules and have the reproducibility of the exact model while being able to "float" along the updates of that branch? I think it always boils down to this: Either commit new gitlinks, so the submodules get updated in a reproducible manner, or don't use gitlinks at all so the submodules can float wherever they want. > So yes, I want my superproject's gitlinks to update automatically. I > just don't know a smart way to make that happen. Yup, that has been the endpoint of all discussions about that topic so far. And until someone comes up with a smart way to make that happen, I would rather not put something half-baked into git. (But please tell us when you found a smart way to do that! ;-) -- 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