Re: [boost] git reset and force push

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