On Thursday 08 October 2015 00:33:22 Raffi Enficiaud wrote:
Le 07/10/15 17:46, Andrey Semashev a écrit :
On 07.10.2015 18:38, Raffi Enficiaud wrote:
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.
It doesn't look cleaner to me. I don't commit to every submodule, that's true, but I do make PRs to many. I don't want to type the commands for each and every submodule I happen to edit. Instead I run two commands I mentioned before (which are in update.sh, conveniently lying in my local directory) and get what I want for all submodules.
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.
That's your interpretation, but I have no problem with that. I am a developer.
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.
I see what you mean, but I don't consider myself as a blind consumer of other Boost libraries of which I'm not a formal maintainer. If I see a bug in Boost.Test I will probably try to fix it myself and create a PR, if I have time. But we're getting philosophical here.
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.
Right. And this is why submodules are badly suited for active development. The design of submodules is good as long as you want a fixed external dependency, which is perfect for snapshots, tags, releases, dependency management and so forth. Though even then I would have second thoughts about using git as a tool for dependency management. As soon as you start developing multiple submodules and try to be on the bleeding edge and keep things working the fixed dependencies only get in the way. This is closer to what is happening in Boost (in my view, at least). The automatic superproject updates are one indication of that, people committing to multiple submodules and doing synchronized changes is another. You may say it's lack of modularization and I'll call it collaboration and historical practice. It doesn't matter. In the end of the day, the way Boost works currently, I don't care if my code worked with 10-commits-old revision of Boost.Test or not - if it doesn't work with HEAD then I have a problem (or you have, if it turns out to be a regression in Boost.Test).