Re: [boost] git reset and force push

Subject: Re: [boost] git reset and force push
From: András Kucsma (r0maikx02b_at_[hidden])
Date: 2015-10-07 09:56:10

On Wed, Oct 7, 2015 at 3:27 PM, Raffi Enficiaud <
raffi.enficiaud_at_[hidden]> wrote:

> 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
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

Please don't force push. According to Github there are 42 people who have
forked
boostorg/test. At least that many people can be affected in very surprising
ways
and many more who're developing locally without a forked Github repository.

To have a nice clean history all the time you have to always work on
non-public
branches and merge to public branches (like develop) only once you're sure
your
change is ready to be public. Until you make it public, you do whatever you
want
with the history.

(btw, non-public branches can be branches published on Github, but not
master or
develop in case of boost)

Please don't force push.

Thanks,
Andras