Stefan Beller <sbeller@xxxxxxxxxx> writes: > On Tue, Jul 4, 2017 at 3:50 PM, Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> wrote: > >> >> I think some invocation of "git submodule update ???" will do the same, >> but I can't from the docs see what that is right now. > > '--remote' is what you are looking for. > > When we have the branch field configured, the workflow for *creating* > the patch sent > to Junio might be different than it currently is. Currently, you would > send a patch that is > produced as: > > git -C sha1collisiondetection pull origin master > git add sha1collisiondetection > git commit -m "serious reasoning in the commit message" > > This could be 'simplified' to > > git submodule update --remote > git add sha1collisiondetection > git commit -m "serious reasoning in the commit message" > > but as we had different branches in the submodule field, > I wonder how much of an ease this is. > > For Junio the workflow stays the same, as he would just > apply the patch, so I understand why he might see the > branch field as pollution. My reaction was more about "the rest of us", not me or those who choose to bind a new/different commit in the submodule to the superproject. I was recalling a wish by submodule users in a distant past that lets "submodule update" to detach to the tip of the named branch in the submodule, regardless of what commit the superproject points at with its gitlink. When those merely following along with this project did "pull && submodule update", I do not want the submodule directory to check out the commit that happens to be at the tip of their 'master' branch. If "submodule update" requires an explicit "--remote" option to work in that way, then my worry is allayed, greatly. Thanks.
