Open Stack

On 11/11/2013 11:55 AM, Birdsall, Dave wrote:
> Hi,
> 
> I'm working on a new project that is moving towards using a clone of
> the OpenStack infrastructure to manage its source and continuous
> integration.
> 
> We are newbies to git (we are used to svn), and have a question about
> master branches.
> 
> On https://wiki.openstack.org/wiki/GerritWorkflow, it describes
> cloning a git repository, and keeping the local master up-to-date
> with the origin master. They then create their local branches off of
> that local master (e.g., using git checkout -b <branch>), and check
> in locally then submit changes to gerrit via git review.
> 
> One of our engineers asks:
> 
> "Why should we advise people to keep their master branch as a copy of
> the master branch in gerrit/github, when they already have an exact
> copy of it? The remote branch is origin/master.  We should just have
> people branch directly from that rather than merge it onto their own
> master, which might have other changes.
> 
> git fetch origin                                                  #
> gets the code, no need to merge it git checkout -b <branch>
> origin/master          # branch from official master, not my local
> master
> 
> Same thing works when updating existing branch:
> 
> get fetch --all git rebase origin/master
> 
> This seems a more straight-forward way of working, rather than
> pulling to the master branch and then branching from there."
> 
> So, we are wondering, why does OpenStack not use the origin/master
> branch directly? I'm wondering if there are implications for how
> gerrit works? Or perhaps it makes a local developer repository more
> tightly coupled to the central repository somehow?

Hi Dave! Welcome to the jungle! :)

It has to do with providing a clear workflow that makes sense when
people have 10's or 20's (or more) of outstanding workstreams.

You are correct, having a local master branch is not necessary, and I
myself do not do this. However, I know what I'm doing with git. We've
found that for beginners, the extra clarity of direct instructions of
"do this every time" that are focused around ensuring that they don't
get themselves into a weird state helps us scale the number of devs,
especially when many of them are new to git (all of the reports of
'everyone knows git' are widely mistaken. We've found that most new
contributors to OpenStack are first-time git users as well)

With that in mind, we try our best to be clear about things, and to not
worry too much about all of the things you _can_ do with git. Rather, we
try to keep it to a grokkable subset, and then let people branch out
from that when they're ready.

Monty