ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Notice: force push on ament/googletest

tl;dr if you have a source checkout of ros2, you may need to take care when updating ament/googletest.

I recommend either deleting the folder (in your workspace would be src/ament/googletest) and re-cloning it, or if you have local changes yourself (unlikely) following one of these suggestions:

As for why, in the process of upgrading the version of googletest we use on our “master”, I fast forwarded to a newer googletest version (https://github.com/ament/googletest/commit/c6cb7e033591528a5fe2c63157a0d8ce927740dc) and then reapplied our few commits on top which make it easier for us to build and release. Because I fast-forwarded and cherry-picked (in order to not diverge from upstream), I had to force push to the ros2 branch.

See also:

git merge -s ours <commitId of previous ros2 branch state> -m 'newly patched upstream changes'

That’s the only additional command needed before your push to avoid anyone having to delete their local folder. The ‘-s ours’ option connects the histories without taking changes and thus never conflicting.

And this is still possible now.

So nothing in your email explains why you think everyone else deleting local folders is preferable to you running one single git command.
I mention this because force-pushing shared branches and then writing emails should be an emergency measure, not an example to follow in the future.

1 Like

In the future I’ll try to do something better, but I did research ways to do it without disruption.

However, I thought that all of them caused the “pulled” changes to get new commit hashes, and so they would not align with upstream googletest any longer, which is what I meant when I said:

But I think your solution might work without that drawback. I’ll try using that next time.


Really, the right solution in my opinion is to embed googletest at the version we require in our repository, either as a subtree or an archive (depending on how big it gets), and then maintain our patches that go on top as actual patch files. Then at build time we can apply the patches, then have cmake build and install it using ExternalProject_Add() or similar. This would also allows us to host multiple versions of googletest at a time if we wanted.

This is what I do in https://github.com/osrf/osrf_testing_tools_cpp (https://github.com/osrf/osrf_testing_tools_cpp/tree/master/osrf_testing_tools_cpp/vendor/google/googletest) and it seems to work fine, and should be ok (repository size wise) as long as we don’t update it frequently (seems to be infrequent).

But I don’t have time right now to address that issue. For now, I assumed this was not very disruptive, but I’m sorry if it caused problems for anyone.