On Mon, Oct 03, 2016 at 12:00:45PM -0700, Junio C Hamano wrote: > Jeremy Morton <admin@xxxxxxxxxxxxxx> writes: > > > At the moment, supermodules must reference a given commit in each of > > its submodules. If one is in control of a submodule and it changes on > > a regular basis, this can cause a lot of overhead with "submodule > > updated" commits in the supermodule. It would be useful of git allows > > the option of referencing a submodule's branch instead of a given > > submodule commit. How about adding this functionality? > > When somebody downstream fetches from your superproject and grabs > the set of submodules, how would s/he know what _exact_ state you > meant to record? When s/he says "I have your superproject commit X, > which binds submodule's branch Y at path sub/, and it simply does > not work. Your project is broken", how do you go about reproducing > the exact state s/he had trouble with to help her/him? > > The only thing s/he knows is that the commit used from the submodule > must be one of the commits that was on branch Y at some point in > time, hopefully close to the timestamp recorded in the commit in the > superproject. And your record in the history of the superproject > does not tell you more than that, so you wouldn't have any idea > better than what s/he already has to help. > > Hence, such a "functionality" will never happen, at least in the > exact form you are describing. > > It is conceivable to add some feature that allows you to squelch the > report that the submodule recorded in your superproject is not up to > date from "git status" etc. to help those who thinks it is OK to not > bind the latest submodule commit to the superproject all the time, > though. We already have options to support these kinds of workflows. Look at the option '--remote' for 'git submodule update'. You then only have to commit the submodule if you do not want to see it as dirty locally, but you will always get the tip of a remote tracking branch when updating. Cheers Heiko