Boost logo

Boost :

Subject: Re: [boost] git reset and force push
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-10-07 20:04:01

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, 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).

Boost list run by bdawes at, gregod at, cpdaniel at, john at