Jeremy Morton [off-list ref] 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.
On Mon, Oct 03, 2016 at 12:00:45PM -0700, Junio C Hamano wrote:
Jeremy Morton [off-list ref] writes:
quoted
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
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.
I wonder if we could make that convenient for users by not tracking
the submodule,
i.e.
* we have the information in the .gitmodules file
* the path itself is in the .gitignore
* no tree entry
Then you can update to the remote latest branch, without Git reporting
a dirty submodule locally, in fact it reports nothing for the submodule.
It sounds like a hack, but maybe it's worth looking into that when
people want to see that workflow.