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 06:01:54

On 07.10.2015 11:43, Raffi Enficiaud wrote:
> Le 07/10/15 09:58, Andrey Semashev a écrit :
>>> You're saying this is not supported. Is that correct? Why not supporting
>>> this? Is it by design?
>>
>> No, I'm not saying that the commit bot can't handle that (it probably
>> can because someone already tried to rewrite history in the past and it
>> kept working). I don't know for sure since I'm not maintaining the bot
>> (or any testers, which may also be affected).
>>
>> I'm saying that rewriting history breaks pulling, which is what
>> developers do when they update local git repos. It is a major nuisance
>> when the history breaks as everyone has to repair their local branches.
>>
>
> Ok, but this occurs only if develop is checked out locally, which does
> not happen when we just do
>
> git submodule update --recursive
>
> So for people that have checked out boost.test develop branch, they
> would need to reset, for the others, it should work, isn't it?

The command above leaves submodules in a detached state. To get a 
working state of submodules, with history and ability to create local 
branches (e.g. for development or pull requests), you have to checkout a 
branch. Because of that I always keep all submodules checked out on some 
branch (typically, develop). Personally, I update Boost with the 
following command:

git pull --recurse-submodules && git submodule foreach git merge --ff-only

I use

git submodule update --recursive --init
git submodule foreach git checkout develop

only on rare occasions, when I know there are new submodules that I want 
to download.

Even barring the pull breakage, IMO tampering with history is not 
something you should be doing to revert changes in the first place. 
History exists for the very reason of reflecting changes made to the 
code along with the comments why those changes were made.

> git submodule update --force libs/test
>
> should do the trick for those who have checked out boost.test[develop].
> What do you think?

I'm not sure what --force means in this command, but I'd rather avoid it 
if possible, because in general --force is not safe.

> Sorry for insisting a bit on this path, but this is the shortest and
> cleanest path now for fixing the C++11 vs. C++03 issues of boost.test.
> In the future, I think I will maintain a "develop-release" branch for
> being able to force push the topics on it (and have our own testing
> infrastructure on that).

I'm not sure what kind of changes there are that require rewriting 
history and cannot be fixed with new commits reverting the older ones. 
The only reason to rewrite history I can imagine is to drop commits to 
reduce the size of the git database. I don't think this is your case though.