On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote: > "W. Trevor King" <wk...@tremily.us> writes: > > > The superproject gitlink should only be updated after > > > > $ git submodule update --pull > > > > A plain > > > > $ git submodule update > > > > would still checkout the previously-recorded SHA, not the new upstream > > tip. > > Hrm, doesn't it make the "float at the tip of a branch" mode > useless, though?
How about having a branch config option and reusing our submodule.$name.update option for specifying whether the user wants to always float to the tip of the branch? 1. If submodule.$name.update is pull it would checkout the specified tip. 2. If submodule.$name.update is checkout or none it would do the usual thing and you need to specify --pull to get the tip. I am still a little bit undecided about an automatically crafted commit. At $dayjob we sometimes update submodules to their tip without any superproject changes just to make sure we use the newest version. Most of the time the commit messages are along the lines of "updated submodule x to master". On one hand Junio is right that the person updating to the newest submodule stuff has no clue what to write in this message. On the other hand someone might as well just use this functionality to get all the tips of all the submodules checked out. He then individually decides which changes to take by using add but will then still use a commit message like the one above. So currently I am more on the "have an automatically generated commit message" side. Its in a similar corner like merge commits, that are also generated, for me. We could have it as the default and a --no-commit option (like merge) for people that want to stage submodules individually. Cheers Heiko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
