----- Original Message -----
From: Ævar Arnfjörð Bjarmason
Date: 9/9/2010 7:06 AM
On Thu, Sep 9, 2010 at 04:47, Joshua Jensen<jjensen@xxxxxxxxxxxxxxxxx> wrote:
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.
Fair.
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?
The end result is the same; submitted code is never really tested
against latest in Perforce either. The primary difference between the
two is that the Perforce submit is successful the majority of the time
(odds of someone editing and submitting the same file as you are low),
and the Git push fails the majority of the time.
Don't get me wrong. I've given training on why Git's enforced
pull-before-you-push model can be better than what we had before
(reproducible state, fewer broken builds, etc). Nevertheless, the issue
is very frequent, and that's why I am querying others.
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.
Agreed, but it appears it is currently a missing feature. There have
been discussions about it on their mailing list over the past months,
and a feature request is in their tracker. I am unsure of their
progress or even interest.
[..]
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?
Unless I'm mistaken, though, it seems to work in reverse of what our
working model has been for years.
I'm grossly oversimplifying the process, but the Linux model seems to be
built on hierarchical 'pull requests'. I can tell a subsystem
maintainer I have some changes and then ask that maintainer to pull them
from a certain location. When that person has time/inclination, the
change is pulled, merged in, and then another pull request is sent to
the upstream hierarchy.
This _is_ compelling, but even if it would work within the company I
work for, it is such a dramatic shift in workflow that I am certain it
could not be done in one fell swoop.
Thanks for your insights!
Josh
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html