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 09:27:26

Le 07/10/15 12:01, Andrey Semashev a écrit :
> 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

Personally I never checkout a submodule unless I have to work on it, 
since I do not need them (!), and a submodule develop/master might not 
be part of any version of the superproject itself (and hence not being 
able to test it). Also with your merge you might create new commits that 
are not on the remote.

If I were to work on a fork, I just add a remote, and check out against 
what I am doing.

That is to say, I am perfectly fine with a detached state. I also think 
that for the reasons I exposed, the way you update your copy is not a 
good practice in general.

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

This is not something I would like to do always. But since our 
boost.test develop branch has this so special value for the other 
libraries in there, and many commits were performed after the point I 
want to revert to, that I want to organize the things a bit differently.

OTOH, the features git provides enable to maintain a much cleaner and 
sharper history, which helps a lot over time.

Since the organization of boost.test is biased by the runners, our 
develop branch will become a kind of release branch (like master for 
other less coupled modules). Our internal develop branch (not called 
develop but something else) will accept force pushes, but this is fine 
since it is not meant to be checked out by anyone but boost.test 
developers.

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

Right, so maybe without the force it would work as well. I believe this 
is not a problem in general, since the submodule command checks out a 
specific commit. But for your case, if you fastforward, some problems 
might happen.

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

I really do not care about the size. I would like to have a clean 
history, with consistent commits organized in topics, being able to 
revert topics as a whole, make topics orthogonal with appropriate 
rebasing etc.

Resetting the develop branch
- would ensure that we go back to a state where we know everything was ok,
- is a fast way of fixing things
- is the least error prone (in terms of commits, not in terms of git 
manipulations).

The purpose of this thread is to have a better idea of the practices of 
boost, also wrt. a potential nondestructive hard reset (non destructive 
in the sense that the commits have been cherry picked on appropriate 
topic branches).

So far, 1 is against :) (but since you are an experienced git user, you 
would not mind neither to reset boost.test).

Best,
Raffi