Le 07/10/15 17:46, Andrey Semashev a écrit :
On 07.10.2015 18:38, Raffi Enficiaud wrote:
Le 07/10/15 17:35, Andrey Semashev a écrit :
On 07.10.2015 18:26, Raffi Enficiaud wrote:
Le 07/10/15 16:52, Andrey Semashev a écrit :
The superproject is automatically updated to refer to the latest commits in develop and master branches. I think it may skip a few pushed commits if pushes are done in quick succession, but really, I don't care. For all practical purposes you can assume that the superproject always refers to the latest commit.
You're counting on the fact that things get updated fast, etc etc.
I'm not. I don't use superproject references to commits.
Sorry for asking this question again, but why? I do not see any added value in doing that, on the contrary I see only shortcomings.
As I said, I want my checked out copy of Boost to be ready for development. That's what I use it for, right?
Right, git submodule update --recursive git submodule update --remote libs/the_library_on_which_I_am_working is ready for development of the_library_on_which_I_am_working. Since your changes are not spanning the full set of submodules (and there are a lot of warnings in Git when you try to commit in a detached HEAD), this way looks cleaner to me. I have no use in having a
particular revision checked out because if I want to test my code, I want to test it against the actual state of Boost. If I want to modify some code (mine or not) I want to be able to commit and not remember whether I'm in a detached state or not.
My opinion is that once you checkout a develop or master branch of a specific module, you are departing from the master/develop branch of the superproject, and you are promoting yourself as a developer of the submodule. In your case and the commands you are using, you become a developer of all submodules. /Developer/ is not exactly a /user/: in the case of boost.test, you are /not/ a developer, you do not care 99.9% of the time what commit boost.test is pointing to, it is just there and pointing to a revision that you use. This is also the same at the superproject level: let's say I am not "rewriting" the history this time, but pointing the superproject (the .git/modules/test/HEAD) boost.test submodule to the commit before things started to break (this is by design of the git submodule machinery, like svn externals). This is currently impossible because of the bot looking for "develop" and bringing it to the superproject, but this is a plausible scheme for managing submodules and the overall stability of the superproject. In this scheme, your approach does not work and what I was saying previously
You're counting on the fact that things get updated fast, etc etc.
has a bit of truth. Yet this is not the way how boost works today. Anyway, thank you for your time! Kind regards, Raffi