Re: [boost] git reset and force push

Subject: Re: [boost] git reset and force push
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2015-10-07 18:33:22

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