Git and not rebasing branches pushed remotely ?

[Ian Young]

> On 26 Sep 2015, at 08:18, Misagh Moayyed <mmoayyed at unicon.net> wrote:
> 
> My general workflow, if it helps as an example, is the following:

This all seems pretty sensible, if not necessarily what we'll all want to do. Of course one of the advantages of Git is that private workflows are, well, private, and only what's in the official repo needs to be controlled.

> I never ever rebase; prefer merge commits better,

In my case, I use both depending on circumstances. For truly long term work in a repository where there's a lot of collaboration, I use something close to your workflow. For shorter term stuff, I do use rebase a fair bit.

> but I guess to your 
> question: there is no way that I know that you could lock git down to 
> disallow rebases to remotes.

This can be done by disallowing non-fast-forward pushes to existing branches through a hook.

In fact, this is how gitolite is currently configured in our deployment, so if you try to push a rebased version of a branch to a public repository it will refuse. You can do it to a personal repository, though, and of course what you do to a private repository on your own machine is between you and your conscience.

This is (mostly) all configurable, but I picked the way we have it set up right now to avoid mistakes being made while everyone gets comfortable.

Scott and I have the ability to change public history if required.

    -- Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5250 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/dev/attachments/20150926/d974a65d/attachment-0001.p7s>