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.