On Wed, Oct 7, 2015 at 3:27 PM, Raffi Enficiaud < raffi.enficiaud@mines-paris.org> 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