[boost] [git] Why are we using Github (was: The any library does not pull cleanly because of a forced update on develop and master)

On Tue, Dec 10, 2013 at 7:40 AM, Dave Abrahams wrote:

"Cox, Michael" writes:

...

I tried to update my local repositories to the latest changes in each submodule:

git pull; git submodule foreach --recursive git pull

When it got to the libs/any submodule, I got the following message:

remote: Counting objects: 27, done. remote: Compressing objects: 100% (2/2), done. remote: Total 6 (delta 2), reused 6 (delta 2) Unpacking objects: 100% (6/6), done. From https://github.com/boostorg/any + 3f0b981...e3e5da6 develop -> origin/develop (forced update) + 38039b3...d35b2d6 master -> origin/master (forced update) * [new tag] 20131209-develop -> 20131209-develop * [new tag] 20131209-master -> 20131209-master

and my editor popped up with a merge commit message to edit. I think that's because the develop and master branches were force updated, re-writing history in develop and master.

If there is not already a policy in place to prevent history rewriting in public branches, we should have one. And if there's a GitHub mechanism for denying the privilege, it should be enabled.

There may be a policy, but as far as I can tell, Github has no easy interface to allow you to enforce it, i.e. set the receive.denyNonFastForwards=true and receive.denyDeletes=true (for all branches) or branch.name>.mergeoptions=--ff-only (setting up fast forward only per branch). Maybe via plugin (like I assume the trac plugin is being used to integrate boost's trac web-site)?

From the git-config man page: receive.denyNonFastForwards

If set to true, git-receive-pack will deny a ref update which is not a fast-forward. Use this to prevent such an update via a push, even if that push is forced. This configuration variable is set when initializing a shared repository. receive.denyDeletes If set to true, git-receive-pack will deny a ref update that deletes the ref. Use this to prevent such a ref deletion via a push. branch.<name>.mergeoptions Sets default options for merging into branch <name>. The syntax and supported options are the same as those of git-merge(1), but option values containing whitespace characters are currently not supported. The last one I'm not sure if it works on the server side. It may be a client side only configuration item. I have seen examples of adding hooks to enforce such restrictions. Which brings me to a question I've been wanting to get answered: why was Github chosen in the first place? I know it's the 900-lb gorilla in public git repository hosts, but I think Bitbucket allows so much more flexibility in configuring your repositories: - Individual branches and wild-card refs can be configured with who is allowed to commit (which can be a group). - Individual branches can be designated as not deletable. - Individual branches can be designated as not rewritable. See Take control with branch restrictionshttp://blog.bitbucket.org/2013/09/16/take-control-with-branch-restrictions/ for more info. If we are still in the acceptance phase of the git conversion (based on some of the comments in the thread this was taken from), maybe we should reconsider Github? What were the advantages of Github vs. other public repositories like Bitbucket? Michael

-Dave

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost