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

Subject: [boost] [git] Why are we using Github (was: The any library does not pull cleanly because of a forced update on develop and master)
From: Cox, Michael (mhcox_at_[hidden])
Date: 2013-12-11 17:19:26

On Tue, Dec 10, 2013 at 7:40 AM, Dave Abrahams <dave_at_[hidden]> wrote:

> "Cox, Michael" <mhcox_at_[hidden]> 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
restrictions<http://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
>