Re: Coping with the pull-before-you-push model

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Sep 9, 2010, 13:06 UTC
Message-ID: <AANLkTikY55ZJvSTqyFKLqwABqnJZuODz3yrc7CFvQf0K@mail.gmail.com>
In-Reply-To: <4C8866F9.1040705@workspacewhiz.com>

On Thu, Sep 9, 2010 at 04:47, Joshua Jensen <jjensen@workspacewhiz.com> wrote:

Show 16 quoted lines

>  After a deployment of Git on a centralized server at my place of business,
> the largest amount of grumbling has been with the pull-before-you-push
> model.  Coming from the file-centric Perforce where you need only have
> latest of just the files you are submitting, the pull-before-you-push model
> has really been a pain in the neck for a large team.
>
> Even with topic branches being used, merges to master occur frequently.  It
> can really be a frustrating battle to get your merged branch pushed to the
> central master branch.  In the time it took you to pull, test, and push,
> someone has probably already pushed before you.  To cope with this, people
> will pull, not bother testing, and immediately push their changes.  Yes,
> this could result in build instability, but it is considered better than
> never being able to make your change live.
>
> (Let's ignore what we should or shouldn't be doing as far as 'development
> practices'.  :)  We're solving the problems one step at a time...)

Let's not ignore that.

Presumably you had exactly the same problem in perforce, i.e. because you only had have the files you were changing checked out in Perforce in the time between `hack && pull && test && push` someone else might have already pushed. Thus what you just submitted wasn't guaranteed to pass tests.

So is the flow in Git where you don't run the tests again, rebase and push and hope for the best any different?

Show 7 quoted lines

> Gerrit provides a compelling model where branches are pushed to the code
> review server in the form refs/for/master, and the given push will always
> succeed.  Code reviews are performed, someone sets the verified bit, and the
> change is submitted and merged to master by Gerrit itself in a queued
> fashion.  Unfortunately, its general "requirement" to squash your branch
> down to a single commit is, possibly, a showstopper.  If it treated a branch
> merge as a group of commits that MUST stay together, that would be perfect.

This sounds like something that's configurable in Gerrit, or should be.

> [..]
>
> Is there another workflow that is successful for your large(-ish) enterprise
> team?

Linux manages to deal with a huge number of commits, but does so by having subsystems.

Maybe that's something you can use in your codebase?